Meeting minutes
[selectmenu] Interoperability of styles
<gregwhitworth> github: https://
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
masonf: if not dominant browsers could go one way and other browser have to match other wise broken sites. how can we do that?
masonf: one way is using appearance prop, appearance: none would be interop mode with minimal styling and standrd min styling across browsers
masonf: could have opinionated styles, accessed via appearance:auto. prefer default is none, so default ootb is interop
masonf: we'd need to standardise agreed styles, which should be minimal. dialog element has a stdized 10 lines of css, like borders etc.
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
masonf: that instance, should not respect CSS and simply display options
masonf: mobile is another option, separate issue for another day
JonathanNeal: mentioned minimal styles, suggest we have multiple min styles if one needed to be shipped
JonathanNeal: because of different affordance, screensizes, kind of input. should a control of this nature have the available system colours.
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
masonf: like based on media queries, have prescribed MQs and different style sheets?
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
masonf: dark mode has them
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
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
JonathanNeal: just want to leave a note that we might need more than one
gregwhitworth: good poiint, they're two separate issues
<JonathanNeal> I like this base concept.
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
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
gregwhitworth: or we bring back the attribute which is confusing for authors. each new control or component, it will be appearance auto or none.
masonf: makes sense to apply default styles, makes sense to have an element.
gregwhitworth: bring it up incase CSS WG reads this and see there are new elements going forward
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?
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?
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
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.. 😝
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
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>.
masonf: theother conversation is what is the default styling, i.e. the interop styling.
<JonathanNeal> +1, and appreciating that it would likely come from a CSS property.
<dandclark> +1 to that resolution
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 }
chrishtr: appearance none has advantages, interop by default, has opportunity for UA to implement an auto if they want to.
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
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.
chrishtr: none will make it easy for them to do what they want, including using 3rd party vendors
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
masonf: there's no way to not use the default styles
masonf: wanbt to address ensuring contrast and a11y
<JonathanNeal> +1 on the updated proposal
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
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
gregwhitworth: depends on the default styles
gregwhitworth: so that's a separate issue, and something we should heavily scrutinize. accessible by default
gregwhitworth: i feel like there are still questions in the proposed resolution
masonf: it leaves open many question, but gets the first part done
gregwhitworth: do we agree that none should be the default?
JonathanNeal: i thought we were agreeing to not deciding
<chrishtr> +1 to resolving on appearance:none as default
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
gregwhitworth: I'm not proposing the base keyword
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.
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
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.
masonf: everyone hates the existing implementation
una: and that would be a reason to change it
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
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
<una> +1 to interoperability
masonf: I also have to talk to UX folks
<chrishtr> I will go convince them :)
gregwhitworth: i will ping webkit folks, if you know folks to loop in then send them the issue
gregwhitworth: any objections? key part is the second part
<tantek> I would say MUST instead of "needs to"
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.
<tantek> (sorry for the delay in typing)
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 must ensure contrast/accessibility between developer-provided CSS and the UA's own opinionated styling.
[popup] Note that popup=async + JavaScript allows custom behavior
<gregwhitworth> github: https://
masonf: take it as an action to spin up issue about default styles
masonf: we've talked about this issue. does popup attributes affect semantics. popup attribute only describes behaviour. all of it is behaviour, none of it is semantics. side thing, popup async to popup=manual
masonf: aligns more with popup=auto, it feels parallel and easier to understand
masonf: a side issue with renaming popup=hint, but a separate issue. last thing is not part of resolution. phase 1 is what we've talked about with 3 values. phase 2 is to define actual elements for some of these usecases with these semantics, like tooltips and notification
masonf: use these values, but semantic elements with base styles
<masonf> Proposed resolution: The popup attribute in HTML will describe only behavior (what it does, such as top layer, dismiss behavior and so on) and not semantics (what it should mean to other tools such as accessibility). Also rename popup=async to popup=manual.
<Zakim> dandclark, you wanted to agree
<gregwhitworth> +1 to the proposal, I don't need to rehash my opinion
dandclark: i agree with these points. we had long conversations about defining semantics for popups as they're used for so many things. feels right to not add semantic baggage. also manual seems reasonable
JonathanNeal: i just want to clarify, does that mean things like role, and aria attributes?
masonf: yes that's correct. you apply attribute to element, that element comes with its own role and how its calculate. it doesn't change
<masonf> una, you have a substantial echo on your audio
<una> +1 the resolution, popup is at risk for a11y concerns, this resolves the concerns and still provides the needed functionality
<una> we can provide demos for common usecases
<una> that are accessible
vicgutt: wrt to a11y, the definition of the element we add attribute to. there would be a dedicated element for these popups? is that correct? and those elements would have the semantics defined
<una> but i'd also want the UA to accessibly focus/apply semantics on the element when popup is open
masonf: yes, but that would be phase 2
<una> Would that mean that folks would still need to use JS for accessible elements?
vicgutt: it would be beneficial to have that
masonf: it's phase 2, but once we have the mechanics, then defining an element becomes a lot easier
<JonathanNeal> Oo, thank you for that great question, vicgutt. Now I feel I can +1 this.
gregwhitworth: semantics for roles, as it relates to aria-haspopup, will that be owned by popup, that would be in the controller code. if i have popup attribute. that anchor is no longer adding aria-haspopup by default. the new element will add that
<una> +1 to make sure popup still provides a11y semantics for popup focus
<una> (regardless of role)
masonf: we're not changing roles, attributes are a grey area.
masonf: the way ATs look at the tree and decides what to do is up to the a11y side of things, how it's interpreted. your question might fall on that side of the line. i'm unclear whether it would be ok for us to haspopup, but good question
<JonathanNeal> Unless we have good element internals for ARIA, messing with just ARIA could still be messy. If I remove the popup attribute, would it also strip the ARIA attributes? Unless I overwrote them?
<una> I have the same questions/concerns as Greg
gregwhitworth: selectmenu does this out of the box. does the popup attribute come bundled with it? they are accessibility ones and make attribute accessible by default. the a11y comes the minute we implement tooltip elements, we'll do that wiring. i like that personally
<JonathanNeal> If only the ARIA attributes existed in CSS, this would be a lot easier.
gregwhitworth: the attribute isn't bringing semantic baggage
masonf: i agree, selectmenu has controller code builtin and wiring is done correctly. maybe we shouldn't be doing anything at all attribute wise
chrishtr: i thought the plan was that there would be not any implied attribute. popup attribute would be behavioural, and wouldn't say anyting about semantics, new elements would instead. and bring their own things like their own implied haspopup
chrishtr: in the meantime ATs can do their best, but devs should add their own aria attributes so ATs now what they're doing
in the meantime until phase 2
chrishtr: what you said about unclear to devs about what's going on, i.e. some attributes imply other things. good the atribute is explicit about behaviour. its a layering of api surfaces, 1. it's speaking to make it easy to achieve larger goals without doing it all at once
chrishtr: 2. for compat, there will be additional types of popups that we've missed, other edge cases. other popup behaviour, they can use it how they want, then we can codify it in Open UI
RESOLUTION: The popup attribute in HTML will describe only behavior (what it does, such as top layer, dismiss behavior and so on) and not semantics (what it should mean to other tools such as accessibility, including the role and aria-* attributes). Also rename popup=async to popup=manual.
<masonf> SORRY, didn't mean to add RESOLVED there.
<masonf> Proposed resolution: The popup attribute in HTML will describe only behavior (what it does, such as top layer, dismiss behavior and so on) and not semantics (what it should mean to other tools such as accessibility, including the role and aria-* attributes). Also rename popup=async to popup=manual.
JonathanNeal: i want to +1 this, and +1 not messing with attributes. could be hard to remember. if i put popup on something, and it implicitly adds an aria attribute, what happens when I remove it
JonathanNeal: would been alot easier to discuss if we brought AT apis to CSS
<JonathanNeal> +1
gregwhitworth: i like the move from async, super confusing for me
masonf: sorry fr accidentally resolving, but added an extra bit on the end
RESOLUTION: The popup attribute in HTML will describe only behavior (what it does, such as top layer, dismiss behavior and so on) and not semantics (what it should mean to other tools such as accessibility, including the role and aria-* attributes). Also rename popup=async to popup=manual.