[selectmenu] Interoperability of styles

[mfreed7]

Forgive me if there's already an issue discussing this, but I couldn't find one.

It will be important that the default styling of <selectmenu> be made interoperable. By that I mean that it should be easy/trivial for developers to get the same appearance across browsers, without dependencies on the particulars of the UA stylesheet's styling of the <selectmenu> element and its parts. However, I believe it should also be possible for UAs to have a default "branded" style for <selectmenu> that is unique across browsers, as is the case for other form controls.

To accomplish this, one approach might be:

1. Specify appearance:none concretely for <selectmenu>, such that <selectmenu style="appearance:none"> looks identical across browsers.
2. Specify that UA stylesheet rules for the <selectmenu> must not contain any !important rules.
3. Specify that UA stylesheet rules do not use the ::slotted() selector to modify styles of slotted content.

I believe that with the above rules (and likely more that I'm not thinking about), it should be straightforward for developers to ensure interoperable styling by simply using selectmenu {appearance:none}. We should be able to write WPTs that confirm the above rules.

Maybe this isn't the right approach though. Ideas?

@chrishtr @domenic @zcorpan

[domenic]

The basic problem with that approach is that it's opt-in interop, instead of the interop-by-default we try to shoot for with new web platform features.

[chrishtr]

There are two interop issues I can think of:

• UA defaults having different layout behavior w.r.t. surrounding content, leading to different layout.
• Developers accidentally relying on a UA style sheet (e.g. they don't override a UA-default blue background because their site likes that blue; it'll look bad in a UA without that blue background, causing interop issues for that other UA)

The first point seems to require a certain amount of well-specified layout for the selectmenu that UAs have to agree on, though it still leaves them free to specify an arbitrary visual look (so long as it doesn't affect layout), and also arbitrary styling of the default selectmenu popup, since it's not part of normal layout.

The second issue can be solved I think by ensuring that the UA stylesheet for selectmenu is inside of the UA shadow DOM, and disallows exposing parts to developers for styling (unless appearance:none is specified). Disallowing parts is necessary to prevent developers from applying a style to a shadow DOM part that accidentally relies on UA style sheet defaults.

[domenic]

I'm not sure how I understand how the second issue is solved by putting the UA stylesheet inside shadow DOM? (Or what that would even mean?)

Consider: UA 1 has a default background of blue for their selectmenu. UA 2 has a default background of yellow for their selectmenu. The web developer tests in UA 1, not UA 2. They write

selectmenu { color: yellow; }

Now they have a nice yellow-on-blue selectmenu in UA1 where they tested. But for users of UA2, the text in the selectmenu is yellow-on-yellow, i.e. invisible!

And this didn't have anything to do with shadow DOM or where the UA stylesheet is.

[chrishtr]

You're right. I take back my comment about the second issue.

[dandclark]

Maybe UAs should only apply author styles to the <selectmenu> if the author has specified appearance: none. This might be annoying for authors but brings us back to interop-by-default.

Alternatively, could UAs automatically switch to appearance: none for a <selectmenu> if they detect that the <selectmenu> or its contents are affected by any author styles? That would be more convenient for authors but I don't know if it's at all feasible.

[mfreed7]

@chrishtr and I discussed this today. Here's a quick summary of our thoughts:

• We agree that we need an "interoperability mode" for <selectmenu>, which guarantees identical visual results across browsers, when given the same HTML and CSS.
• Perhaps this "interoperability mode" should be the default, or perhaps it should be opt-in. It seems to us like this should be the default, but we'd love to hear developer input.
• There seem to be three options on the table for controlling this mode:
  • The CSS appearance property, where none would indicate interoperable behavior, and auto would indicate UA-themed appearance. The default could be none, if we want "interoperability mode" by default.
  • (Suggestion from @dandclark above) Automatically switch between modes, based on which CSS or HTML was detected.
  • Maybe we only need the interoperable mode. One concrete example of this is the <dialog> element, which has a basic standardized set of styles, and no UA-specific styling. It seems like the vast majority of developers will want to style the <selectmenu>, given that this is basically the entire point of building this new element. So perhaps this meets nearly all use cases anyway?
• However the "interoperable" mode is controlled, we will need to come to agreement on exactly what those styles should be. Given the difficulty of that, we think the interoperable styles need to be fairly minimal, again similar to the ones for <dialog>. Note that these styles do produce some visual output, such as setting border sizes and text/background colors. But just enough to make the control usable absent any CSS.

[zcorpan]

I thought that the idea was to only have the interoperable mode for <selectmenu>. If you want a native select, you can use <select>, at the tradeoff of being limited to plain text for the options' labels.

We can still add a native mode to <selectmenu> later, and use appearance: auto as the opt-in.

[mfreed7]

I thought that the idea was to only have the interoperable mode for <selectmenu>. If you want a native select, you can use <select>, at the tradeoff of being limited to plain text for the options' labels.

We can still add a native mode to <selectmenu> later, and use appearance: auto as the opt-in.

I like that as a plan. Interoperable by default (though appearance:none by default), and a styled version if UA’s want to provide it, via explicit appearance:auto.

[gregwhitworth]

It's worth reviewing this issue that I opened on this a while back: w3c/csswg-drafts#5998

And the base keyword to appearance in the explainer.

I like that as a plan. Interoperable by default (though appearance:none by default), and a styled version if UA’s want to provide it, via explicit appearance:auto.

So the premise is that browsers that implement <selectmenu> will have the interoperable stylesheet by default? Given that the expectation is that over time these new controls/components will replace their current counterparts are UAs ok having very generic solutions ship by default? Given the discussions we had with Chromium revamp between MS and Google I doubt that would be the case given the focus on interactions, shadows, colors, etc. I could be wrong though.

[css-meeting-bot]

The Open UI Community Group just discussed [selectmenu] Interoperability of styles, and agreed to the following:

• RESOLVED: the <selectmenu> will have a "mode" that makes it have the same, standardized default styling. The appearance property will control this mode, with none being "interoperable" and auto being "UA opinionated styling". The default value for `appearance` for <selectmenu> must be "none". In 'auto' mode, the UA needs to ensure contrast/accessibility between developer-provided CSS and the UA's own opinionated styling.
• RESOLVED: the <selectmenu> will have a "mode" that makes it have the same, standardized default styling. The appearance property will control this mode, with none being "interoperable" and auto being "UA opinionated styling". The default value for `appearance` for <selectmenu> must be "none". In 'auto' mode, the UA must ensure contrast/accessibility between developer-provided CSS and the UA's own opinionated styling.

The full IRC log of that discussion

<gregwhitworth> Topic: [selectmenu] Interoperability of styles
<gregwhitworth> github: https://github.com//issues/536
<andrico1234> masonf: interoperability for selectmenu visually, we need to have this interoperable in all the ways, if author drops selectmenuy in the page and uses it in differentbrowser looks the same
<JonathanNeal> q+
<andrico1234> masonf: if not dominant browsers could go one way and other browser have to match other wise broken sites. how can we do that?
<andrico1234> masonf: one way is using appearance prop, appearance: none would be interop mode with minimal styling and standrd min styling across browsers
<andrico1234> masonf: could have opinionated styles, accessed via appearance:auto. prefer default is none, so default ootb is interop
<andrico1234> masonf: we'd need to standardise agreed styles, which should be minimal. dialog element has a stdized 10 lines of css, like borders etc.
<gregwhitworth> q+
<andrico1234> masonf: minimum would be border, but need to figure this out. one thing, add something to spec to allow UA if unable to apply styles. display options in some way, e.g. if a selectmenu is on a watch
<andrico1234> masonf: that instance, should not respect CSS and simply display options
<andrico1234> masonf: mobile is another option, separate issue for another day
<gregwhitworth> ack JonathanNeal
<andrico1234> JonathanNeal: mentioned minimal styles, suggest we have multiple min styles if one needed to be shipped
<andrico1234> JonathanNeal: because of different affordance, screensizes, kind of input. should a control of this nature have the available system colours.
<andrico1234> JonathanNeal: component like select menu has a little more going on,there may be a need for more than one visual affordance for UA select menu
<andrico1234> masonf: like based on media queries, have prescribed MQs and different style sheets?
<andrico1234> JonathanNeal: could native controls, but not form controls. there could be media queries with these default styling, but haven't seen much with native components
<andrico1234> masonf: dark mode has them
<andrico1234> masonf: there's a lot of bikeshedding about what the styles should look like, and what i've brought up should come into play. before we go down that route, do we want to agree whether this a route we want to go down
<andrico1234> gregwhitworth: regardless of select menu, future controls doesn't matter, control styles should be interop. we'll file that issue, then you can file another issue on what the min styles proposal is
<andrico1234> JonathanNeal: just want to leave a note that we might need more than one
<andrico1234> gregwhitworth: good poiint, they're two separate issues
<JonathanNeal> I like this base concept.
<andrico1234> gregwhitworth: we've given bas appearance proposal before, we spoke about appearance auto. we hadn't agreed to having new elements, but because of that the premise of interop DOM was a requirement, they resolved that this is required to achieve the goal of stylable controls
<andrico1234> gregwhitworth: they wanted it as an attribute due to the mobile aspect. going forwar,d if we want appearance auto or none. it does submit that everything going forward would have to be a new element
<andrico1234> gregwhitworth: or we bring back the attribute which is confusing for authors. each new control or component, it will be appearance auto or none.
<andrico1234> masonf: makes sense to apply default styles, makes sense to have an element.
<gregwhitworth> ack gregwhitworth
<andrico1234> gregwhitworth: bring it up incase CSS WG reads this and see there are new elements going forward
<dandclark> q+
<gregwhitworth> ack dandclark
<gregwhitworth> q+
<andrico1234> dandclark: i support that we need to standrdize stylesheets, we want it interop by default, and ensure browsers are onboard, but don't customise it however they want. can we get browsers on board?
<andrico1234> dandclark: default should be the boring interop stylesheets, and the last suggestion developers can opt-in to UA's preferred styles via appearance: auto. will UAs be in board with this though?
<andrico1234> una: it does take a UX person to make this decision, i can't speak to UX overview of Chrome, not sure what othe UAs will be thinking. there's benefits for developers but can't say one way or another
<masonf> q+
<chrishtr> q+
<andrico1234> gregwhitworth: i don't see how default is the boring thing, but just my opinion, would like to what Tantek's position is. can see default checkbox by default looks bad, by a UX perspective, i like this approach because I can choose apperance: none and have everything removed
<JonathanNeal> If browsers start shipping consistent base styles, how will we reinvent normalize css files every few years? Hmm?! Didn’t consider that, huh.. 😝
<andrico1234> gregwhitworth: so by default the UX is decent, and i can choose my own colours. i can argue the otherside just as easily. as long as we can make it a css property i'll be thrilled
<gregwhitworth> ack masonf
<gregwhitworth> ack gregwhitworth
<andrico1234> masonf: i agree, there will be two discussions across browsers. whether opt-in or opt-out. my opinion is the same as every developer, css stylable, default shouldn't be unstylable
<masonf> Proposed resolution: the <selectmenu> should have a "mode" that makes it have the same, standardized default styling. We should use the appearance property to control this mode, with none being "interoperable" and auto being "UA opinionated styling". We need to decide on a default value for appearance for <selectmenu>.
<andrico1234> masonf: theother conversation is what is the default styling, i.e. the interop styling.
<vicgutt> q+
<gregwhitworth> ack chrishtr
<JonathanNeal> +1, and appreciating that it would likely come from a CSS property.
<dandclark> +1 to that resolution
<andrico1234> chrishtr: it won't be difficult for devs for the default be none, or much of an impact if the default is auto either
<JonathanNeal> Also looking forward to *, ::before, ::after { appearance: base; box-sizing: border-box }
<andrico1234> chrishtr: appearance none has advantages, interop by default, has opportunity for UA to implement an auto if they want to.
<andrico1234> chrishtr: auto mode has more complications, what do you do if the developer provides stylesheets that changes colours, but doesn't adhere to colour contrast, so auto could ignore dev stylings for accessibility reasons
<andrico1234> chrishtr: developers can use it to apply styles given to them by their designers, and they can move on. i predict it will be uncommon for developers to go with auto
<masonf> Proposed resolution: the <selectmenu> should have a "mode" that makes it have the same, standardized default styling. We should use the appearance property to control this mode, with none being "interoperable" and auto being "UA opinionated styling". We need to decide on a default value for appearance for <selectmenu>. In 'auto' mode, the UA needs to ensure contrast/accessibility between developer-provided CSS and the UA's own opinionated styling.
<andrico1234> chrishtr: none will make it easy for them to do what they want, including using 3rd party vendors
<andrico1234> una: accent colours works for default styles, a lot of people use accent colour and are excited by it, so more people use default than you may realise
<andrico1234> masonf: there's no way to not use the default styles
<andrico1234> masonf: wanbt to address ensuring contrast and a11y
<JonathanNeal> +1 on the updated proposal
<gregwhitworth> ack vicgutt
<andrico1234> chrishtr: would be difficult to substantially change existing select menu, due to web compat concerns. i predict the same kind of thing would happen with appearance:auto, classified as something we can't change and develoeprs just throw stylesheets so it will be anything they want it to be
<andrico1234> vicgutt: Agree with Una, wrt to accent colours, if default is appearance none instead of auto, then couldn't that cause a11y issues, a general question
<andrico1234> gregwhitworth: depends on the default styles
<andrico1234> gregwhitworth: so that's a separate issue, and something we should heavily scrutinize. accessible by default
<andrico1234> gregwhitworth: i feel like there are still questions in the proposed resolution
<andrico1234> masonf: it leaves open many question, but gets the first part done
<andrico1234> gregwhitworth: do we agree that none should be the default?
<andrico1234> JonathanNeal: i thought we were agreeing to not deciding
<chrishtr> +1 to resolving on appearance:none as default
<andrico1234> masonf: clarify, none means standardized set of miniumal styles that are consistent across browsers, interop. auto would have UA specific styles. resolution is that default is none
<andrico1234> gregwhitworth: I'm not proposing the base keyword
<andrico1234> JonathanNeal: none is what i thought base was
<JonathanNeal> +1 even more the third time
<masonf> Proposed resolution: the <selectmenu> should have a "mode" that makes it have the same, standardized default styling. We should use the appearance property to control this mode, with none being "interoperable" and auto being "UA opinionated styling". The default value for `appearance` for <selectmenu> should be "none". In 'auto' mode, the UA needs to ensure contrast/accessibility between developer-provided CSS and the UA's own opinionated styling.
<andrico1234> gregwhitworth: my only feedback, is that it's MUST andnot SHOULD. MUST be none
<tantek> +1 to gregwhitworth
<tantek> this feels like a really big step forward
<andrico1234> una: as a developer I agree with this, best path for developers. i don't know if i was in charge with UX or browser whether I would put a gold stamp on this
<masonf> Proposed resolution: the <selectmenu> will have a "mode" that makes it have the same, standardized default styling. The appearance property will control this mode, with none being "interoperable" and auto being "UA opinionated styling". The default value for `appearance` for <selectmenu> must be "none". In 'auto' mode, the UA needs to ensure contrast/accessibility between developer-provided CSS and the UA's own opinionated styling.
<andrico1234> masonf: everyone hates the existing implementation
<andrico1234> una: and that would be a reason to change it
<andrico1234> masonf: i changed all the shoulds to wills
<JonathanNeal> -1...
<tantek> +1 masonf everyone hates the existing situation, and the "market" didn't converge on its own (UI control styling), so we need to solve it with a standard
<JonathanNeal> ...just kidding. +1!
<JonathanNeal> agreed with what tantek just added, too
<andrico1234> gregwhitworth: we can always revert it, but would recommend all browser vendors to chat with UI/UX folks that own shipping componnets, to get buy-off. we have a path forward we just switch and say default is auto. then developers can use appearance none
<gregwhitworth> q?
<una> +1 to interoperability
<andrico1234> masonf: I also have to talk to UX folks
<chrishtr> I will go convince them :)
<andrico1234> gregwhitworth: i will ping webkit folks, if you know folks to loop in then send them the issue
<andrico1234> gregwhitworth: any objections? key part is the second part
<tantek> I would say MUST instead of "needs to"
<masonf> RESOLVED: the <selectmenu> will have a "mode" that makes it have the same, standardized default styling. The appearance property will control this mode, with none being "interoperable" and auto being "UA opinionated styling". The default value for `appearance` for <selectmenu> must be "none". In 'auto' mode, the UA needs to ensure contrast/accessibility between developer-provided CSS and the UA's own opinionated styling.
<tantek> (sorry for the delay in typing)
<masonf> RESOLVED: the <selectmenu> will have a "mode" that makes it have the same, standardized default styling. The appearance property will control this mode, with none being "interoperable" and auto being "UA opinionated styling". The default value for `appearance` for <selectmenu> must be "none". In 'auto' mode, the UA must ensure contrast/accessibility between developer-provided CSS and the UA's own opinionated styling.

[mfreed7]

A resolution so nice, we resolved it twice.

I've opened #552 to discuss what the default styling should be. I don't believe there are other embedded questions that weren't answered, but if someone has one, please raise a fresh issue. I'm going to close this one.