Styling form control pickers

As part of the discussion around appearance: base colleagues and I presented a vision of how this could work. The idea outlined in that presentation is that stylability of form control pickers (the overlay box for select options, selecting a date, etc.) would have its own independent opt-in. This is because we think that form controls (excluding their pickers) can probably be mostly done all at once with a simple appearance: base switch and accompanying pseudo-elements. This avoids the cost to authors of having to learn and match a variety of base-* values.

Form control pickers however are quite a bit more involved and we expect it to take longer to tackle them and some we expect will never be stylable (e.g., the file picker). The idea is that when a form control uses appearance: base you can address its picker using ::picker(form-control-identifier) and independently set that to appearance: base as well. E.g., select, select::picker(select) { appearance:base } would give you a stylable select. ::picker(form-contorl-identifier) would represent the outermost box of the form control picker and additional pseudo-elements will be needed to address the various pieces it consists of.

Thanks for making an issue for this! I imagine I could replace the ::select-fallback-datalist or ::select-datalist pseudo-element that I've implemented and proposed with ::picker(select) and have everything work the same.

I like how this enables incremental opt-in, but would still require us to implement/ship appearance:base for all the non-picker form controls to truly make it incremental, right?

I also like how it enables appearance:base for the button and the popup separately, but I imagine that some authors wouldn't like the additional CSS needed to go from select { appearance:base-select; } to select { appearance:base; } select::picker(select) { appearance:base; }.

Just catching up on the latest status on this. I want to advocate for simplicity for this feature from a user (author) perspective.

It doesn't seem like there is a benefit to developers (or a difference) between select { appearance:base; } and select::picker(select) { appearance:base; }. Why force developers to remember both selectors that they will need to target, degrading the developer experience?

The most likely and straightforward developer experience would be to name these selects, i.e. with a class, and access them like .account-dropdown { appearance: base; /* styles */ }. Ideally that is all that would be needed to enter into this new behavior, and we wouldn't require an additional pseudo class. With the picker proposal, developers would need to write:

.account-dropdown {
  appearance: base;
  /* styles */
}

.account-dropdown::picker(select) {
  appearance: base;
}

(As an aside, would styles need to be duplicated? Where would they live, on the select itself or on the ::picker pseudo?)

Similarly, I would prefer not to have custom identifiers with specified names for each type of select. ::picker(form-control-identifier) is a more roundabout authoring experience than just targeting your element via a class or other developer-owned identifier. This requires developers to remember the custom identifier for each type of picker in addition to the custom class name they have likely selected to target the picker. In reality, developers will likely need to be looking up these identifier values to make sure they're getting them right.

A natural developer experience would be to connect their custom code like:

.profile-color {
  appearance: base;
  /* rest of your styles */
}

Rather than connect it and then look up the correct picker to sync with:

.profile-border-color {
  appearance: base;
  /* rest of your styles */
}

.profile-border-color::picker(color) {
  appearance: base;
}

Is it possible to infer the types here to prevent this additional lookup and code for a more seamless developer experience?

It doesn't seem like there is a benefit to developers (or a difference) between select { appearance:base; } and select::picker(select) { appearance:base; }. Why force developers to remember both selectors that they will need to target, degrading the developer experience?

I agree with Una that this adds extra overhead for developers. Under the premise that we ship appearance:base for all in-page form controls at once before doing select and other ones with pickers it makes sense as an incremental opt-in for compatibility, but I don't think that chromium is going to ship appearance:base for other form controls before select.

Maybe a middle ground would be to make select::picker(select) { appearance:base; } imply select { appearance:base; } so you only have to write one of them instead of both?

We initially brought up appearance:base-select as a value for incremental opt-in for select first, and select::picker(select){appearance:base} works as an incremental opt-in for in-page elements first.

I'm starting to question the value of having an incremental opt-in at all if both of them have a significant burden on the developer. We could use css @supports to feature detect support for certain elements.

Anne and Una both seemed to say similar things about each solution, which is why I think we should just make it appearance:base on one element to get everything:

This avoids the cost to authors of having to learn and match a variety of base-* values.

Why force developers to remember both selectors that they will need to target, degrading the developer experience?

The CSS Working Group just discussed Styling form control pickers.

The full IRC log of that discussion

<keithamus> jarhar: I'd like to get to the second issue because it can affect how we name the pseudos.
<keithamus> 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.
<keithamus> ... so this would be alternative for e.g. appearance: base-select opt in for each rule
<keithamus> ... one problem is that Chrome is looking to ship select first, so opt in for page pickers is not that helpful
<keithamus> ... on top of that Una posted a comment about it being more of a developer burden for developers to do this on each picker
<keithamus> ... IMO we should have appearance:base on root element for everything without incremental opt in
<keithamus> ... the push back was incremental opt in but una and anne are talking about the same issue regarding opt in
<keithamus> ... ???
<keithamus> ... the author has to remember more things for each element.
<keithamus> ... the whole thing is brought up as a need for incremental opt in
<una> q+
<keithamus> ... but we can add support for supported elments, tweak style to show it didnt apply properly or isn't supported on this element yet.
<gregwhitworth> q+
<keithamus> ... I think it simplifies it.
<gregwhitworth> ack fantasai
<gregwhitworth> ack gregwhitworth
<jarhar> q?
<jarhar> q+
<keithamus> 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.
<keithamus> ... 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
<keithamus> ... it may be that developers are find with not-in-page pickers but want to style in-page
<keithamus> ... ???
<keithamus> ... thats why its incremental on the picker. to enable incremental styling of the in-page then add the picker
<keithamus> ... 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.
<keithamus> ... 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.
<keithamus> ... Allowing us to ship in pieces.
<gregwhitworth> ack una
<masonf> q+
<gregwhitworth> q+
<keithamus> 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
<keithamus> ... 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.
<keithamus> ... 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.
<keithamus> 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.
<keithamus> ... then we make a new @supports for each one
<keithamus> ... in your @supports rule you could style each one.
<keithamus> ... 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
<ntim> q+
<jarhar> q?
<keithamus> una: so would this work with the picker opt in?
<keithamus> ... 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
<keithamus> 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
<keithamus> ... 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.
<keithamus> ... obviously they want both but in-page seems to be the most desired.
<keithamus> ... could we have it magically propagate? Maybe but that would be super weird
<keithamus> una: and the other way around, base on the in-page propagating to picker doesn't resolve the issue you're brining up?
<keithamus> 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
<keithamus> 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
<keithamus> 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
<masonf> q?
<ntim> native picker have special capabilities such as expanding outside of the window bounds for instance
<keithamus> 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.
<keithamus> ... bigger projects will, e.g. delta really wants their calendar to look like a delta calendar
<fantasai> +1 jensimmons
<keithamus> ... 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
<keithamus> 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
<chrishtr> q?
<una> q+
<keithamus> 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.
<keithamus> ... 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.
<keithamus> ... but its impossible to do ALL in-page and pickers all at once.
<keithamus> ... tackle all in-page controls all at once and pickers one by one
<gregwhitworth> ack jarhar
<keithamus> 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
<keithamus> value to the root element, to ship select first.
<gregwhitworth> ack masonf
<keithamus> 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
<keithamus> ... 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
<keithamus> ... for example putting rich content in the picker shows up in the base control.
<keithamus> ... 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.
<keithamus> ... 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.
<keithamus> ... let's make it as easy as we can for developers
<chrishtr> opt-out is a good idea
<keithamus> 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
<keithamus> opt-in/out for pickers, but I agree with masonf
<keithamus> ... 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/
<keithamus> ... some may go faster than others but there is such disparity between even UAs as to what they do
<keithamus> ... 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...
<gregwhitworth> ack gregwhitworth
<keithamus> ... but we'll need that for appearance:base
<gregwhitworth> ack ntim
<chrishtr> opt-out gives a way to get a native picker
<keithamus> 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.
<keithamus> ntim: having appearance:base toggling on everything goes against that.
<keithamus> ... from a design systems view pickers will likely be different going control-by-control.
<keithamus> gregwhitworth: most design systems to have base foundationals
<keithamus> 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.
<keithamus> ntim: you dont want 1 control to have native, and others to have base-styled. You want consistency.
<jarhar> q?
<gregwhitworth> ntim I want to +1 that the picker feature possibly being useful, I think I disagree with them being native by default
<keithamus> ... 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.
<gregwhitworth> ack una
<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
<keithamus> 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
<keithamus> control
<keithamus> ... this gives users more capability to customise in-page control vs pickers
<keithamus> ... right now we don't give users choice on picker
<keithamus> ... currently there is some styling with appearance:base-select. Users don't necessarily need to customise it
<jensimmons> q-
<keithamus> ... this could open the door for new controls having custom styles for appearance:base. We could do more there, e.g. 3d...
<jensimmons> q+
<keithamus> ... ???
<gregwhitworth> ack fantasai
<gregwhitworth> q+ fantasai
<keithamus> 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
<keithamus> ... 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
<gregwhitworth> ack jensimmons
<gregwhitworth> ack fantasai
<jensimmons> And Apple is working on in-age controls now, coming up with a proposal to share when it's ready.
<jensimmons> *in-page
<keithamus> 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
<keithamus> represented as elements in the page.
<keithamus> ... most other form controls have pickers with UA magic
<keithamus> ... it might be reasonable to ship appearance:base-select just for selects, while we work on the rest, then ship appearance:base for everything
<jarhar> agree
<keithamus> ... so we can split the difference
<masonf> +1 to that approach!
<chrishtr> +1 to base-select
<keithamus> ... we dont want values foe every form control but a short-term phase for select seems reasonable and acceptable.
<gregwhitworth> Zakim, end meeting

I wanted to pull out the answer to this question: “Why force developers to remember both selectors that they will need to target [element itself and ::picker() pseudo-element], degrading the developer experience?”

The issue isn't that we can't feature detect. The incremental opt-in per picker type is for compat reasons. Authors will often use a more general selector than is needed then opt in, and expect it to continue to not to take effect on the elements it currently doesn't take effect on. But then we end up with "we cant ship appearance: base" on, say, date controls, because they weren't in the original set, and shipping that changes existing pages that weren't expecting it. Now we need a new keyword appearance: base-no-really-including-date-pickers. That's why we need an incremental opt in.

The reasons we split into in-page and not-in-page: First, we believe we can pull together the necessary standardisation/implementation work to do in-page controls within a reasonable amount of time, but styling pickers is a multi year project. Something we'll have to do incrementally. Second, it may be that developers want to style in-page controls to ensure they match the page's aesthetic, but don't mind the picker being native--either because they don't have the budget to do full styling of all the pickers, or because they prefer the OS controls (which may have abilities or affordances that in-page ones don't, for example, being able to pop out of the viewport). Pop-ups that have native styling are much less disruptive aesthetically than in-page controls that can't be styled (such as filepicker buttons), so it's a natural break point.

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 all at once. We can make the argument optional after we've made them all styleable--in that case authors can just use ::picker() without the keywords--but this gives us a gradual transition towards that world, allowing us to ship in pieces.

(Many thanks to @keithamus for the excellent minutes.)

Thank you all for the great call today!

We didn't have time on the call today, but I wanted to re-affirm that I'm all for landing as many controls at once as possible to avoid having too many base-foo keywords. That said, one thing I would like to ask @fantasai based on this statement:

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

What is your plan on how to accomplish this? We'd need to divide this work up asap across the teams to align on parts, pseudo elements, behaviors, and then produce the base stylesheet so that they can then be implemented across the numerous usecases that these components/controls provide. Happy to sync up in some other way to meaningfully put together a project plan as we'll need this regardless of how we intend to roll this out.

Thanks for the discussion everyone! I’d like to build a resolution based on fantasai’s comments at the end of the meeting:

fantasai: …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

I’d like to propose the following resolution:

appearance:base-select opts-in both the in-page control and the picker for <select>.
::picker { appearance: base } will be used for all form control elements (including <select>) as an opt-in/incremental shipping plan, per Apple’s proposal
appearance:base will apply to the in-page parts of all form controls (including <select>)

That would mean base-select has to remain a magical value. That doesn't seem good.

@annevk what do you propose as an alternative?

Making the opt-in for the picker separate as we had tentative agreement on initially. That's more compatible with the model we plan for the future and would allow base-select to become an alias for base in due course.

If I'm understanding correctly (I might not be), that revises the proposed resolutions to:

appearance:base will apply to the in-page parts (only) of all form controls (including <select>), and, to avoid forwards-compat problems, must ship simultaneously on all form controls.
::picker(keyword) { appearance: base } will apply to form control pickers as an opt-in to styleable pickers of the named control type, with the control-type keyword allowing per-control-type incremental shipping of styleable pickers. To avoid forwards-compat problems, we will consider a keywordless variant only once all form controls can be opted in.
If appearance: base on all in-page controls is not ready in time for <select>, we may add appearance: base-select whose behavior is equivalent to appearance: base, but only applies to <select> and its picker (::picker(select)).

The CSS Working Group just discussed Styling form control pickers.

The full IRC log of that discussion

<emilio> jarhar: last time we talked about appearance: base and base-select and applying it to `::picker()`
<emilio> ... looks like both me and fantasai proposed some text we can resolve on
<emilio> ... I think we have some subtle differences between the proposals
<emilio> ... we don't want to burden the dev to force them to apply appearance: base to put appearance in two different places
<emilio> ... I think that's the fundamental disagreement
<emilio> annevk: I think it's hard to go into this with this discussion without knowing Google's longer-term vision
<jarhar> q?
<masonf> q+
<emilio> ... on our vision the picker and the controls are individually styleable
<emilio> ... but Google has mostly focused on select
<jarhar> q+
<astearns> ack masonf
<emilio> masonf: few things, I think we really like the idea of doing it all at once, but it sounds difficult
<jarhar> would putting appearance:base on ::picker() also apply to the main element work?
<emilio> ... I'm glad it seems ok to do appearance: base-select to carve out of that
<emilio> ... I think we should do the same for other controls
<emilio> ... one thing we've discovered with <select> is that they're not independent
<emilio> ... it's difficult to allow customization of the in-page thing
<emilio> ... without accounting for the whole popup and everything
<emilio> ... e.g. for date pickers the most common use case is displaying something else along the date
<dandclark> q+
<emilio> annevk: that feels like a new semantic capability for that control
<una> q+
<emilio> ... we're just talking about styling the page controls as they are today
<emilio> masonf: our opinion is that for most things styling the picker is the main wanted feature
<emilio> ... e.g. if you want a flag on a `<select>` option
<emilio> annevk: we might be seeing different feedback
<emilio> ... I've seen feedback where authors are just trying to get basic form styling working accross UAs and that's hard
<emilio> ... it has been hard for a long time, even just having full control of the box
<emilio> q+
<jarhar> q?
<emilio> masonf: I've heard the same feedback for stuff like checkboxes
<jarhar> q-
<emilio> ... but it's possible, people do it, they put that work
<ntim> `::picker(select) { appearance: base }` is pretty straightforward to write honestly, and you can already write whatever styles you want on `select`
<emilio> ... the things that are impossible are the things people complain about
<emilio> ... and are the things we should focus
<emilio> ... if we just did some of the work for the date picker for example then we'd have complains about not having done the work for the popup
<emilio> annevk: that seems it'd need additional markup which could be the opt-in
<emilio> ... we will continue to add new features to these controls
<emilio> ... to me the sooner we get the appearance: base stylesheet
<emilio> ... the better, then we have the infra for new markup features we can opt them into that
<emilio> masonf: I think that might be too optimistic, devil is in the details
<emilio> ... I want to have the appearance-<control> fallback plan in place
<astearns> ack dandclark
<emilio> dandclark: echoing what masonf said, the feedback we get is about styling the control
<emilio> ... the thing that worries me is the long-term dev experience
<emilio> ... if we do base-{select,range,...} there's a path to make appearance: base apply to anything
<chrishtr> q+
<astearns> ack una
<emilio> ... if we have the different picker stylability, do we have the same long-term possibility of not having the double opt-in?
<emilio> una: echoing a lot of what dandclark mentioned
<emilio> ... one thing that hasn't been brought up is how intrincate the picker and the buttons are
<emilio> ... splitting that opens a can of worms for a lot of the controls
<masonf> Anne: british airways uses native <select> and therefore *can't* style the popup
<emilio> ... even for annevk's example, they don't do it because they can't
<annevk> q+ To say that discoverability as to whether appearance:base applies to a picker would also be lost if it's not toggled separately.
<emilio> ... I think that's a testament of why they need to be tied together
<emilio> ... the more that we dig into it the most nuances we find
<emilio> ... the pickers are very tied to their controls
<ntim> I think people tie the pickers more to modals rather than their in-page controls when it comes to writing design systems
<astearns> ack dbaron
<emilio> dbaron: there was something annevk said about the complaints developer have being things about simple styling
<emilio> ... I think one of the things that happens when you focus on the complaints that people have is you focus on things that people could /almost/ do
<emilio> ... there's another way to look at it
<emilio> ... why are authors building their own widgets rather than using the native?
<masonf> Great viewpoint. Developers build their own: selects, date pickers, color pickers, etc...
<emilio> ... I think that's an important q because using the built-in has a lot of advantages
<emilio> ... and when you ask that you get to different conclusions
<chrishtr> q?
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<emilio> ... hard for me to say what the Google strategy is, but I think there's a lot of thinking about figuring out what to do about these users and making them possible
<emilio> ... and I think that explains some of the different conclusions about why tying them together is important
<emilio> ... that might involve other semantic changes, like what masonf mentioned about date pickers
<astearns> ack emilio
<dbaron> ScribeNick: dbaron
<jarhar> q?
<dbaron> emilio: I think I also added myself to the q to react about styling in-page buttons being difficult.
<dbaron> emilio: I think that's true of many controls, such as range.
<dbaron> emilio: but others are fairly consistent
<dbaron> emilio: and to be honest the ones I'm aware are difficult to style are the ones that don't have pickers, like range and slider and progress etc.
<dbaron> emilio: people want to do cool stuff with them
<dbaron> emilio: I think I'm with una that splitting customizability, esp. if we allow pages to use appearnce:base only on the picker, that seems like a can of worms we don't want to get into.
<dbaron> ScribeNick: emilio
<astearns> ack chrishtr
<emilio> chrishtr: I'd like to focus on the points of agreement
<emilio> ... looking at the latest comments
<ntim> emilio: I brought this up last time, but using the native picker can be a design choice
<emilio> ... fantasai rephrased everything to three bullet points
<emilio> ntim: that's the opposite of what I meant tho
<emilio> ... the main disagreement is about whether the select keyword would apply to both or just the select
<emilio> ... I wonder if we can resolve on what fantasai commented on the issue, then discuss about having a single or two opt-ins
<emilio> annevk: I think you can get it in one line :)
<dbaron> fantasai's comment was https://github.com/w3c/csswg-drafts/issues/10440#issuecomment-2303554166 (I assume)
<ntim> This is the opt-in in how we ideally see things: `::picker(select) { appearance: base }`
<ntim> or `select, ::picker(select) { appearance: base }` if you the base stylesheet on the select
<emilio> annevk: I still don't have a satisfactory answer on how to make appearance: base apply to everything without tackling all pickers
<emilio> ... like color
<emilio> ... I like the focus on the individual controls
<emilio> ... but it misses looking at the whole
<emilio> ... which is what leads to this clash
<una> q+
<emilio> ... for the color thing you need to know "is there a picker", opt in the picker, did the UA decide to honor my request for custom picker
<Zakim> annevk, you wanted to say that discoverability as to whether appearance:base applies to a picker would also be lost if it's not toggled separately.
<emilio> ... so appearance base would end up computing to auto on the picker for e.g. color inputs on a watch
<ntim> Then in the future once all the pickers are styleable, people can just use `::picker`, along `dialog` and whatever modal-like things exist
<emilio> astearns: any reservations on fantasai's comments
<emilio> emilio: I think the second point is the concern una and myself were talking about, which would allow a base-appearance picker without a base-appearance control
<emilio> una: I think we don't want to block <select> on figuring out the color picker for example
<emilio> chrishtr: it's not blocking, we would just not support the ::picker(color) syntax
<emilio> emilio: not sure we want the ::picker() { appearance: base } unconditionally
<emilio> astearns: let's bring this back to the issue and try to get consensus there

If I'm understanding correctly (I might not be), that revises the proposed resolutions to:
* `appearance:base` will apply to the in-page parts (only) of all form controls (including `<select>`), and, to avoid forwards-compat problems, must ship simultaneously on all form controls.

I think Google was ok with this, with the caveat that they want appearance: base-select, (and maybe appearance: base?) to opt in both the button and the picker, but they wanted it to move to a separate issue.

* `::picker(keyword) { appearance: base }` will apply to form control pickers as an opt-in to styleable pickers of the named control type, with the control-type keyword allowing per-control-type incremental shipping of styleable pickers. To avoid forwards-compat problems, we will consider a keywordless variant only once all form controls can be opted in.

I think this is fine (not ideal tho), with one caveat, which is that we should either define how this would work when the control is not appearance: base (which feels a bit of a can of worms), or explicitly state that it doesn't work (so ::picker(keyword) { appearance: base } only does something if you've done foo { appearance: base }).

* If `appearance: base` on all in-page controls is not ready in time for `<select>`, we may add `appearance: base-select` whose behavior is equivalent to `appearance: base`, but only applies to `<select>` and its picker (`::picker(select)`).

That means select { appearance: base-select } would do something different to select { appearance: base }, right? That seems a bit unfortunate... Would be good that, if we have the chance, we make appearance: base apply to the picker as well at the same time?

After the discussion yesterday, and giving @annevk’s remarks some more thought, we actually agree that it seems best to have separate opt-in’s for the in-page control and the picker, even in the case of <select>. So despite our comments yesterday, we’re in favor of adopting @fantasai’s proposed three bullet points, as-is. As mentioned by @emilio, we will have to work through exactly what happens in the two “mismatched” cases, where the picker is native and the in-page is “base”, or vice versa. That’ll take some work, but it seems tractable. It's possible we run into some roadblocks and we'll have to revisit those here. But otherwise we'll get started thinking about it. Your input would be appreciated!

Separately, there was a request made for Google to provide our own more-explicit “vision” for how to go about this form redesign process, and we’re working on that. More to come.

I am imagining a future in which authors may also provide custom pickers replacing the UA's pickers, even the system ones. E.g. an advanced color or date picker. So basically what people are working around right now due to the lack of stylability and customizability.

To stay consistent, it would be great if those pickers could be targeted the same way across all form controls providing pickers.

I currently don't have a concrete proposal for how that would work, though I wanted to mention it to keep future extensibility of this feature in mind.

Sebastian

::picker(identifier) should only match when the in-page control is not using native appearance (i.e., not for appearance: auto; only for base and possibly none if it can be done compatibly). At least I got the impression that we generally didn't want pseudo-elements to match in-page controls with native appearance (although we might have to make some legacy exceptions I suppose).

The other way around the picker would start out with native appearance until you set it to base (and that's supported on the platform in question).

::picker(identifier) should only match when the in-page control is not using native appearance (i.e., not for appearance: auto; only for base and possibly none if it can be done compatibly). At least I got the impression that we generally didn't want pseudo-elements to match in-page controls with native appearance (although we might have to make some legacy exceptions I suppose).

The other way around the picker would start out with native appearance until you set it to base (and that's supported on the platform in question).

Ahh ok, good, thanks for the clarification. So there's only one "mismatched" case: where the picker is native and the in-page is “base”. Not vice-versa.

Separately, there was a request made for Google to provide our own more-explicit “vision” for how to go about this form redesign process, and we’re working on that. More to come.

On this topic, we've written up some thoughts. Rather than post a giant comment on this thread, I've opened a fresh issue just to make it easier to read: https://github.com/w3c/csswg-drafts/issues/10804

After the discussion yesterday, and giving @annevk’s remarks some more thought, we actually agree that it seems best to have separate opt-in’s for the in-page control and the picker, even in the case of <select>. So despite our comments yesterday, we’re in favor of adopting @fantasai’s proposed three bullet points, as-is. As mentioned by @emilio, we will have to work through exactly what happens in the two “mismatched” cases, where the picker is native and the in-page is “base”, or vice versa. That’ll take some work, but it seems tractable. It's possible we run into some roadblocks and we'll have to revisit those here. But otherwise we'll get started thinking about it. Your input would be appreciated!

Proposed resolution: https://github.com/w3c/csswg-drafts/issues/10440#issuecomment-2303554166

The CSS Working Group just discussed Styling form control pickers, and agreed to the following:

RESOLVED: `appearance:base` will apply to the in-page parts (only) of all form controls (including `<select>`), and, to avoid forwards-compat problems, must ship simultaneously on all form controls.
RESOLVED: `::picker(keyword) { appearance: base }` will apply to form control pickers as an opt-in to styleable pickers of the named control type, with the control-type keyword allowing per-control-type incremental shipping of styleable pickers. To avoid forwards-compat problems, we will consider a keywordless variant only once all form controls can be opted in.
RESOLVED: If appearance: base on all in-page controls is not ready in time for <select>, we may add appearance: base-select whose behavior is equivalent to appearance: base, but only applies to <select> and its picker (::picker(select)), individually.

The full IRC log of that discussion

<chrishtr> gregwhitworth: please help out Joey & team if you can
<chrishtr> jarhar: have a comment proposing and linking back to Elika's proposed resolution, we'd like to resolve on that
<chrishtr> jarhar: is anyone against adopting this resolution?
<gregwhitworth> q?
<chrishtr> jarhar: first: appearance: base will apply to the in-page parts of form controls, and to avoid compat problems must be shipped for all controls
<una> q+
<fantasai> https://github.com/w3c/csswg-drafts/issues/10440#issuecomment-2303554166
<fantasai> appearance:base will apply to the in-page parts (only) of all form controls (including <select>), and, to avoid forwards-compat problems, must ship simultaneously on all form controls.
<fantasai> ::picker(keyword) { appearance: base } will apply to form control pickers as an opt-in to styleable pickers of the named control type, with the control-type keyword allowing per-control-type incremental shipping of styleable pickers. To avoid forwards-compat problems, we will consider a keywordless variant only once all form controls can be opted in.
<fantasai> If appearance: base on all in-page controls is not ready in time for <select>, we may add appearance: base-select whose behavior is equivalent to appearance: base, but only applies to <select> and its picker (::picker(select)).
<chrishtr> jarhar: the ::picker(...) function will opt overlay pickers to base style, parameterized by control
<emilio> q+
<emilio> ack una
<chrishtr> jarhar: appearance:base-<control> would opt in a specific in-page control if needed for incremental adoptoin
<chrishtr> una: currently the implementation / discussion then opting in the picker without the base, then nothing will happen. Want to make sure we have consensus on that behavior.
<chrishtr> fantasai: are you saying that you want to make sure that if the picker is opted in but not the base element, then the picker opt-in will have no effect?
<chrishtr> una: yes.
<chrishtr> masonf: think this falls out of the existing definition, but yes need agreement
<chrishtr> una: second question: resolution says appearance: base will apply to all, but we don't have a full list of controls
<chrishtr> fantasai: currently only have a specific opt-in for just base-select, but hopefully the rest in one go
<chrishtr> una: what about the date picker or color picker? would we have to block on that?
<chrishtr> fantasai: no, because appearance: base for non-picker opts in just the in-page aspects of the control
<chrishtr> fantasai: if you want the styleable version of the picker then then you'd need to separately opt in that
<jarhar> q?
<chrishtr> una: why can't we have appearance: base for pickers only?
<chrishtr> fantasai: for web compat reasons
<gregwhitworth> q+
<chrishtr> emilio: I think what Una was asking was opting in via appearance:base just on the picker because it requires ::picker
<sanketj_> q+
<chrishtr> emilio: what I understand Una saying is that if you restrict it to ::picker(select) then it'd be just for select anyway
<jarhar> q?
<chrishtr> fantasai: if we're introducing the base-select keyword anyway then it doesn't matter much
<chrishtr> emilio: agree
<gregwhitworth> ack emilio
<fantasai> s/then it doesn't matter much/then why would we risk the compat of making base valid at all/
<chrishtr> emilio: want to make sure that we're not resolving that appearance:base-select on the in-page element would opt in the picker also
<chrishtr> chrishtr: correct, it does *not* opt in the picker alkso
<chrishtr> dbaron: there are only 3 modes: both auto, in-page base, and in-page + picker base
<fantasai> 1. Native styling of in-page and picker - do nothing (`appearance: auto`)
<fantasai> 2. in-page base, native picker -> input { appearance: base; }
<gregwhitworth> ack sanketj_
<fantasai> 3. in-page base, styleable picker -> input, ::picker(type) { appearance: base; }
<dbaron> s/both auto/both not base/
<chrishtr> sanketj_: clarifying question: we're saying that appearance:base applies to all controls but only applies to in-page. then we have appearance-<name> that opts in just one thing?
<chrishtr> sanketj_: will we able to incrementally opt in additional controls?
<chrishtr> fantasai: setting aside base-select as an exception, there would not be a per-control opt-in syntax
<chrishtr> fantasai: second part is that ::picker has a per-control syntax for all pickers
<chrishtr> sanket_: worried we'd get into a state where if we did one more control we wouldn't be able to add it incrementally
<chrishtr> fantasai: because select is ready soon to ship we have a carve-out for it
<chrishtr> fantasai: select also has a picker that is real DOM elements in base mode
<masonf> Proposed resolution: `select {appearance:base-select}` opts in the in-page <select> element. `::picker(select) {appearance:base-select}` opts in the picker for <select>. Future in-page controls will be opted in together, via `* {appearance:base}`. Future pickers will be opted in individually, via `::picker(controltype) {appearance:base}`.
<masonf> q+
<masonf> q+ to discuss my new proposed resolution text
<chrishtr> sanketj_: arrangement I would prefer is that until appearance:base is available for all controls then we'd have per-control opt in via the dashed syntax
<una> q+
<chrishtr> fantasai: yes it doesn't allow that for that. but if in the future something big comes up then we can reconsider it
<chrishtr> fantasai: webkit representatives believe we can do it in one go for in-page controls
<gregwhitworth> ack masonf
<Zakim> masonf, you wanted to discuss my new proposed resolution text
<chrishtr> sanketj_: would prefer text in the resolution allowing future opt-ins
<fantasai> I think we should take the resolutions 1-by-1
<gregwhitworth> ack gregwhitworth
<fantasai> +1 masonf
<gregwhitworth> ack una
<chrishtr> mason: propose to resolve. resolutions never preclude future reconsideration
<dbaron> (maybe clarify in the last sentence that opting in the picker also requires opting in the in-page control)
<chrishtr> una: third point does seem to still be ambiguous?
<masonf> Proposed resolution: `select {appearance:base-select}` opts in the in-page <select> element.
<una> 👍
<chrishtr> fantasai: that's just an ambiguitity in my texxt, Mason's is clear
<astearns> +1
<gregwhitworth> Proposed Resolution: `appearance:base` will apply to the in-page parts (only) of all form controls (including `<select>`), and, to avoid forwards-compat problems, must ship simultaneously on all form controls.
<masonf> +1
<fantasai> +1
<chrishtr> +1
<una> SGTM
<gregwhitworth> Proposed Resolution: ::picker(keyword) { appearance: base } will apply to form control pickers as an opt-in to styleable pickers of the named control type, with the control-type keyword allowing per-control-type incremental shipping of styleable pickers. To avoid forwards-compat problems, we will consider a keywordless variant only once all form controls can be opted in.
<fantasai> +1
<gregwhitworth> RESOLVED: `appearance:base` will apply to the in-page parts (only) of all form controls (including `<select>`), and, to avoid forwards-compat problems, must ship simultaneously on all form controls.
<gregwhitworth> Proposed Resolution:` ::picker(keyword) { appearance: base }` will apply to form control pickers as an opt-in to styleable pickers of the named control type, with the control-type keyword allowing per-control-type incremental shipping of styleable pickers. To avoid forwards-compat problems, we will consider a keywordless variant only once all form controls can be opted in.
<masonf> +1 to the second proposed
<fantasai> +1
<chrishtr> +1
<zcorpan> +1
<una> SGTM
<gregwhitworth> RESOLVED: `::picker(keyword) { appearance: base }` will apply to form control pickers as an opt-in to styleable pickers of the named control type, with the control-type keyword allowing per-control-type incremental shipping of styleable pickers. To avoid forwards-compat problems, we will consider a keywordless variant only once all form controls can be opted in.
<masonf> Proposed resolution: If appearance: base on all in-page controls is not ready in time for <select>, we may add appearance: base-select whose behavior is equivalent to appearance: base, but only applies to <select> and its picker (::picker(select)), individually.
<masonf> (note the individually)
<masonf> +1
<fantasai> +1
<una> +1
<emilio> +1
<zcorpan> +1
<chrishtr> +1
<bkardell_> +1
<chrishtr> LINUX!
<gregwhitworth> RESOLVED: If appearance: base on all in-page controls is not ready in time for <select>, we may add appearance: base-select whose behavior is equivalent to appearance: base, but only applies to <select> and its picker (::picker(select)), individually.
<chrishtr> sanket_: just want to make sure that we can come back later and reconsider things in general

I created a spec PR to define ::picker() here, please take a look: https://github.com/w3c/csswg-drafts/pull/10865

(nit) @josepharhar there is a duplicated = in the production rule for ::picker() that messes up its extraction as a selector by w3c/reffy. ~~I also suspect that you might want ::picker(<type-selector>#) but I have not read all the comments above.~~ (edit: never mind, it probably matches ::part(<ident>+))

w3c / csswg-drafts

Styling form control pickers #10440