Open Bug 1584752 Opened 5 years ago Updated 2 years ago

Options in HTML select have a layout box, differently than other browsers

Categories

(Core :: Layout: Form Controls, defect, P3)

defect

Tracking

()

Tracking Status
firefox71 --- affected

People

(Reporter: mgol, Unassigned)

Details

For a <select> element with some <option> sub-elements, those options have a layout box in Firefox, contrary to latest Safari, Chrome & Edge (with EdgeHTML). This manifests by the options having:

  • non-zero offsetWidth & offsetHeight properties (0 in other browsers)
  • 'getClientRects()having a length of1(0` in other browsers)

See the test case: https://output.jsbin.com/bawosuv - in non-Firefox browsers the results for the first & second (with an explicit display: none) cases are identical.

IE 11 has zero offsetWidth & offsetHeight but getClientRects()'s length is 1 but that's a legacy browser and the behavior already changed in EdgeHTML.

This discrepancy was reported to jQuery in https://github.com/jquery/jquery/issues/4463, see the associated discussion.

It looks like a layout (or maybe UI widget) issue.

Component: DOM: Core & HTML → Layout

Yeah, this part is not specified, as far as I can tell, but we right now rely internally on the options having a layout box to do stuff like computing the <select> width.

Also changing this would effectively cause https://bugs.chromium.org/p/chromium/issues/detail?id=799465 in Firefox for example.

So it's not clear to me what we should do here, whether Blink / WebKit should match Firefox, or vice versa. Any strong opinions?

Also worth checking what other browsers do with <select size=2> for example... Just tested and they do create a layout box for that.

So probably worth raising against the CSS WG, as both behaviors have pros and cons.

Component: Layout → Layout: Form Controls
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.