Open
Bug 1476051
Opened 7 years ago
Updated 2 years ago
Interop issues with select element styling with appearance:none.
Categories
(Core :: CSS Parsing and Computation, enhancement, P3)
Core
CSS Parsing and Computation
Tracking
()
People
(Reporter: twisniewski, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [webcompat])
Select elements with appearance:none render with different default widths in Firefox and Chrome, WebKit, or Safari.
This causes subtle interop issues with site layouts. Perhaps the most major issue is that Firefox adds extra padding to the select, in two forms.
The first is that it bases the width of the select on its widest option's size, and options seem to have some extra default padding (controllable in CSS). Oddly this padding seems to only be used for this calculation these days, and not when rendering the actual dropdown.
The second is that the selects have their own "mystery padding" on the left, in addition to whatever the options themselves contribute. It seemingly cannot be controlled by CSS at all.
For interop here we should not apply either form of padding when -moz-appearance:none is applied to the select.
Those two issues aside, there are other minor interop issues I noticed when the select element has no option elements;
- Chrome gives such selects zero padding and margins, collapsing them to zero width.
- Edge also gives them zero margins or padding, but then gives them an uncontrollable intrinsic width of ~7px, dependent on font.
- Safari does the same as Edge, but also gives them a default margin (controllable via CSS).
- Firefox does the same as Edge, except that the uncontrollable intrinsic width is oddly ~22px instead of ~7px, if the select has no inner markup at all (as opposed to having a whitespace node). That is,
- <select> </select> -> ~7px
- <select></select> -> ~22px
This is quite a mess, though I don't suspect if it's worth pursuing interop for such edgy cases. I do feel that we should probably at least make Firefox consistently apply the narrower width.
Flags: webcompat?
Updated•7 years ago
|
Priority: -- → P3
Comment 1•6 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Webcompat Priority: --- → ?
Comment 2•6 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Updated•5 years ago
|
Webcompat Priority: ? → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•