– DRAFT –
CSSWG + Open UI + WHATWG/HTML

<gregwhitworth> github-bot, take up w3c/csswg-drafts#10462

[css-ui] Pseudo-elements for stylable select

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10462.

jarhar: Both the pseudo elements for appearance base mode. Two issues, ???... should these elements cover the author provided thing or the button/datalist not be a target of the pseudo elements

The author provided button element; should the element target the author provided or just the fallback? There are trade-offs here.
… Could be developer convenience but could have complications. How does it work with animations, subtree, etc.
… There might be styles we could fall back but not both, so we'd need to invent some internal pseudo element to target the fallback
… Might be better for developers if it targets both

gregwhitworth: when you go to change it, its no longer the element. I don't know the technical reasons emilio is pushing back on, but as a dev when I replace it I now own that element so wouldn't expect pseudo to work.

fantasai: we have several elements that replace default; button, dropdown, I think we have to think about when a dev is styling they might not know exactly how the control is put together.
… It might be implemented as native for a while, upgraded to datalist, you didn't change your stylesheets, you're using a component library...
… I can definitely see why you'd want them to match. The other technical concerns are certainly real.
… From authoring it would be more convenient and more robust.

emilio: I think I get both points. As author, I agree with Greg but if you have more generic styles it can be nice to have a single selector. As a component library, presumably they'd export the dropdown in some other way e.g. shadowpart or shadowdom so you cannot target directly yourself.
… Given theres no precedent. Given the complications; like we have a bunch of APIs for exposing pseudo element stuff. Eg getanimations with subtree true returns pseudo element animations, but it would be weird to behave that way... you kind of want the element reference if you have the pseudo but can't do that with shadow root
… Causes inconsistencies with various APIs like this.
… Plus there are usecases for e.g. targeting built in UA one. It's just less complicated to explain if you use pseudo to match the provided, and otherwise not.

fantasai: I meant component library in a much more general sense, like not just web components but CSS libraries or templates or something

emilio: but then changing implementation from built-in datalist to custom one is a breaking change but no more changing than, for example, changing a button to a link
… if you're using a 3rd party library you need to be mindful of these changes and breaking the API

jarhar: sounded like people are in favor of both sides?

gregwhitworth: We could straw poll or take it back to the github issue.

fantasai: from the agenda it looks like we have this one issue which is a superset of lots of small issues. Can we split this up?

gregwhitworth: you want to tackle this as 4 separate ones?

fantasai: if they're independently resolvable filing separately makes it easier to focus on each one

chrishtr: we could resolve on one of those

gregwhitworth: would we want to have a default position?
… if an element gets replaced, the pseudo element being applicable irregardless of which one it is - do we want to resolve on that first?

jarhar: that's one of the three.

fantasai: I'd agree we should be consistent
… as for which way, I feel like we've heard from two or three people

jarhar: I think we discussed this in openui before, a vague memory of people preferring the ???

<gregwhitworth> keithamus: if we allow the pseudo's to target the author provided is the way to differentiate between author and useragent provided?

<fantasai> ::button:not(button)

<gregwhitworth> fantasai: yes, because you could...

<gregwhitworth> ^ typed out her example

<gregwhitworth> keithamus: is that more difficult than than the reverse

<gregwhitworth> keithamus: if I want to select for the built-in verse user provided; which one is more complicated

emilio: I think especially since you cannot use pseudo elements in :not()... I think fantasai's suggestion might not work without changes to pseudo syntax.
… we don't reveal tag name of the pseudo element. You'd need select:has(datalist:thepsuedo) which is kind of annoying

<emilio> `select:has(> button)::button` or so

chrishtr: so this would be in favour of not ???. Like reducing complexity

chrishtr: if there's additional engine complexity in trying to match both at the same time, let's go with just the built-in. Let's developers in a straightforward way to differentiate and avoids complexity in the engine

gregwhitworth: curious; two jobs to be done: when would I really want to differentiate? To interrogate if there's a user provided vs user-agent provided element.
… I get fantasai's use case. The component library, there's a contract there... but its low probability. What's the use case though keithamus?

<gregwhitworth> keithamus: I don't think I have a good answer to that to be honest

dbaron: if we go down the path of making pseudo only match built-in, if the author provided ones are in some cases - I don't know how complex - but if they're complex they could have a pseudo class, to match an existing element. A pseudo class is a thing that matches what you already have, vs a pseudo class to match an element that exists in the UA

shadow. One way to do it.

emilio: I dont think the rules here are particular complicated. You need to be a direct child of the select element, so I don't think the pseudo class is necessary. The reason for interrogating if it's a built-in, if you're not a built-in you can do more complex styling of the innards. If you have a big CSS codebase and 2 ways of addressing the

same thing in subtly different ways, it's not amazing but you could want
… to target the built-in with basic styles and non-built-in for more complex styles. If the pseudo matches both you need to undo the pseudo rules with non pseudo selectors.

<chrishtr> +1, good point

<fantasai> Option 1: Pseudo-element selectors apply to both the user-provided and UA-provided elements in a particular role

gregwhitworth: two foundational positions for this base one that informs the 3 other issues. User submitted will or won't apply. Should we take this back to the issues? I feel like I'm in favour of _not_ having them to apply to user-provided. Is there a strong reason to go in the other direction?

<fantasai> Option 2: Pseudo-element selectors apply only to the UA-provided elements in a particular role

gregwhitworth: does anyone have a strong position

<fantasai> Option 2.1: Also provide a pseudo-class to select to user-provided (and UA-provided?) elements in a particular role.

gregwhitworth: does anyone oppose doing a straw poll?

fantasai: I didn't fully catch what dbaron's position on pseudo classes was.

jarhar: I think it could differentiate what the element was selecting

<fantasai> 1.1: And also provide a pseudo-class on differentiating whether it's a real or pseudo element.

dbaron: you could do either way! But perhaps it's better to leave the sub-options out of the straw poll.

<chrishtr> option 2

<emilio> 2

<jarhar> 2

<ntim> 2

gregwhitworth: for straw poll we'll just do the main options. Please put opion 1 or option 2 in IRC

<fantasai> abstain

2

<gregwhitworth> 2

<astearns> abstain

<dbaron> 2 (weakly)

RESOLUTION: Pseudo-element selectors apply only to the UA-provided elements in a particular role

emilio: for the library use case, I think we resolved on the pseudo element kind of a part-like pseudo. If we were really concerned about providing the same API as a component library we could make exportparts work to expose the inner pseudo elements. Then you could expose the same API in both

gregwhitworth: does this resolve the other issues jarhar?

jarhar: I think it could be worth raising 1 new issue for each pseudo, asking should it exist and what should it be named. WIth that in mind we can close this issue

chrishtr: what are the three issues?
… 1 is the one we resolved
… 2 is do we need them
… 3 is what are their names?

jarhar: yes

chrishtr: are we ready to discuss 2 or 3 yet?

gregwhitworth: yes I think it's a bookkeeping issue

chrishtr: jarhar could make issues after the meeting and copy the resolutions

<gregwhitworth> github-bot, take up w3c/csswg-drafts#10440

Styling form control pickers

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10440.

jarhar: I'd like to get to the second issue because it can affect how we name the pseudos.

jarhar: Proposal to have incremental opt in for elements with pickers using ::picker psuedo which you could add appearance:base on to get the new styling for the picker itself.
… so this would be alternative for e.g. appearance: base-select opt in for each rule
… one problem is that Chrome is looking to ship select first, so opt in for page pickers is not that helpful
… on top of that Una posted a comment about it being more of a developer burden for developers to do this on each picker
… IMO we should have appearance:base on root element for everything without incremental opt in
… the push back was incremental opt in but una and anne are talking about the same issue regarding opt in
… ???
… the author has to remember more things for each element.
… the whole thing is brought up as a need for incremental opt in
… but we can add support for supported elments, tweak style to show it didnt apply properly or isn't supported on this element yet.
… I think it simplifies it.

fantasai: the issue isn't can we feature detect, incremental opt in is for compat reasons. Authors will use a more general selector than is needed then opt in, but then we end up with "we cant ship appearance: base" on, say, date controls. Now we need a _new_ keyword appearance: base-no-really including date pickers. That's _why_ we need an opt in.
… the reason we split into in page and not-in-page. We believe we can pull together the necessary standardisation/implementation work to do this within a reasonable amount of time, but styling pickers is a multi year project. Something we'll have to do incrementally
… it may be that developers are find with not-in-page pickers but want to style in-page
… ???
… thats why its incremental on the picker. to enable incremental styling of the in-page then add the picker
… The reason we have picker with a bunch of identifiers is that we don't anticipate being able to tackle handling all of the pickers consistently and thoroughly in a single ship.
… We can make the picker identifier optional after a certain point, authors can just use ::picker without the keywords, but this gives us a gradual transition towards that.
… Allowing us to ship in pieces.

una: thanks for the explanation fantasai. I've been playing with it quite a bit, the biggest aversion to the current proposal is having to do this in multiple places and remembering the names of all the pickers, in order to get this to work properl
… ideally authors would not have to remember that and just do it in one place

<fantasai> Totally agree that this would be better. We just think it's not possible due to anticipated compat restrictions.

una: I think jarhar mentioned doing @supports to incrementally adopt. We cant use @supports to detect outside of CSS. What are your thoughts there?

<fantasai> But at least this gets us to a world where that can be possible in the future.

jarhar: @supports whether appearnace: base supported on specific elements. If we ship select first and you put it on input type=range that'll still be auto. We add an @support and we can say that works, we still need a unique identifier for that.
… then we make a new @supports for each one
… in your @supports rule you could style each one.
… then if you put html in your select is a separate html thing, it would still support the new structure just render in the native browser way

una: so would this work with the picker opt in?
… so Anne mentioned putting appearance:base on both the base element and the ::picker(type-of-picker). Is it possible to make it just in one place, e.g. the pseudo element

fantasai: that would only select the picker, you could apply styles to the picker only. Setting appearance base on that would make the picker base, but the in-page control still auto
… even before pickers are stylable we want the in-page control to opt into appearance:base. We think authors want in-page styling _the most_, over the pickers.
… obviously they want both but in-page seems to be the most desired.
… could we have it magically propagate? Maybe but that would be super weird

una: and the other way around, base on the in-page propagating to picker doesn't resolve the issue you're brining up?

fantasai: yeah. Its possible authors don't want to put in the effort to style pickers, just in-page, so it's useful to have the difference, but it also allows us to incrementally ship these features. So we don't run into compat issues

una: I'm curious if you've had feedback from authors about if they don't want to style pickers vs in-page?

<ntim> I could see developers wanting a native picker and base-styled in-page

fantasai: we haven't heard that specifically but the main thing driving the design is how to opt things in with minimal impact without memorising weird keywords, which we agree is undesirable but we need some way to handle opt in

<ntim> native picker have special capabilities such as expanding outside of the window bounds for instance

jensimmons: we've not done specific research for e.g from big corporate partners but remembering what it's like to be a web designer on a smaller budget, everything in-page needs to be represented in brand but budget restricts from designing every single thing, so we might want to style the select but not be able to style the picker.
… bigger projects will, e.g. delta really wants their calendar to look like a delta calendar

<fantasai> +1 jensimmons

jensimmons: but where budgets are much smaller I think it'll be common that they want in-page styles but no budget to worry about styling the picker

una: I see where you're coming from. I'd like to do more research. I've heard it's currently hard to style the picker, not the button

jensimmons: asking for select menu, asking for calendars, this is what we hear a lot but thinking through styles - it's difficult. Styling buttons can be styled however you want but oh, unless its input type=file.
… it would be very annoying to roll out changes to all controls one-by-one. It's a better project to do all at once.
… but its impossible to do ALL in-page and pickers all at once.
… tackle all in-page controls all at once and pickers one by one

jarhar: fantasai mentioned ::picker for compat for incremental opt in. All in-page first, then incrementally with pickers. masonf & chrishtr - correct me if I'm wrong but we can't do all in-page at once? And we want to ship select first? Still seems best for developers to me to have appearance base on root element, or ::picker(select) apply its

value to the root element, to ship select first.

masonf: important to remember this is compat. We can do appearance:base and eat the risk, or two options: appearance:base-something or ::picker(something). Both are ugly but both work
… but working on select for 5 years and talking to developers. All in-page controls are pretty stylable. The really tricky bits are stuff like select where there's a picker
… for example putting rich content in the picker shows up in the base control.
… I find it really unlikely well be able to ship all in-page in a year. I think each will have to be shipped hollistically, in its entirety, picker and all.
… having said all that, if that's all true it seems to me that we should make it easy for developers to opt in to each control.
… let's make it as easy as we can for developers

<chrishtr> opt-out is a good idea

gregwhitworth: I think there's 3 options. I haven't heard not caring about the picker a ton, but I personally lean towards... we all want appearance:base, I want to do *{appearance:base}. But to go to una's point, if I did that on select I'd expect it to apply to picker. Doesn't mean picker pseudo can't exist, we don't have to throw the premise of

opt-in/out for pickers, but I agree with masonf
… so before we even talk about base we have to talk about the parts,e.g. file. How do we lay them out? Whats the base styles for that/
… some may go faster than others but there is such disparity between even UAs as to what they do
… so I think there are 3 options, appearance:base being north star, but same for gap, flex-gap grid-gap sucks let's just use gap...
… but we'll need that for appearance:base

<chrishtr> opt-out gives a way to get a native picker

ntim: I want to emphasize on the value of the pickers having a different appearance. A native picker could be a design choice. e.g. on visionOS you might want the nice native picker going out of system bounds. There's value in picker being native.

ntim: having appearance:base toggling on everything goes against that.
… from a design systems view pickers will likely be different going control-by-control.

gregwhitworth: most design systems to have base foundationals

ntim: yeah I am saying most design systems wouldn't want to style a specific control, in-page and picker. They'd separate by in-page vs picker.

ntim: you dont want 1 control to have native, and others to have base-styled. You want consistency.

<gregwhitworth> ntim I want to +1 that the picker feature possibly being useful, I think I disagree with them being native by default

ntim: like in the future I would see systems libraries doing *::picker{appearance:base} or *{apperance:base} for in-page. This is the future I see.

<jarhar> we could make select { appearance:base; } imply select::picker(select){appearance:base} and then you could also apply select::picker(select){appearance:auto} to make the picker go back to the native appearance

<jarhar> there are also existing ways to style the in-page part of select with appearance:none which we could extend with the new content model that allows an author button

una: +1 to appearance:base being north star. Changing way to opt into form controls. Theoretically users would be able to connect any button to the picker using invokers, that would give them control for any page control, whatever control that is. We talked about selectoption linking to any form control, e.g. outside of select, controlling the

control
… this gives users more capability to customise in-page control vs pickers
… right now we don't give users choice on picker
… currently there is some styling with appearance:base-select. Users don't necessarily need to customise it
… this could open the door for new controls having custom styles for appearance:base. We could do more there, e.g. 3d...
… ???

jensimmons: what's great about appearance:base is it switches the very different operating system controls - per platform - its very hard to override those. appearance:base gives everyone a consistent control, same in each browser

<ntim> gregwhitworth: it's already the current default though

jensimmons: I'm responding to hearing people say it's not hard to design in-page controls. Putting your own styling on e.g. checkboxes right now is annoying. Doing it across all would be very valuable to all developers

<jensimmons> And Apple is working on in-age controls now, coming up with a proposal to share when it's ready.

<jensimmons> *in-page

fantasai: I think we at apple generally disagree we can't ship apperance:base all at once. We think its doable within the next year or two, and not take as long as doing all of the pickers. In terms of select specifically, it's special, google's been working hard on it but it's also a form control where the picker and all components can be

represented as elements in the page.
… most other form controls have pickers with UA magic
… it might be reasonable to ship appearance:base-select just for selects, while we work on the rest, then ship appearance:base for everything
… so we can split the difference
… we dont want values foe every form control but a short-term phase for select seems reasonable and acceptable.

<jarhar> agree

<masonf> +1 to that approach!

<chrishtr> +1 to base-select