Styling form control pickers

[annevk]

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.

[josepharhar]

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; }.

[una]

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?

[josepharhar]

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?

[josepharhar]

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.

[josepharhar]

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?

[css-meeting-bot]

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

[fantasai]

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.)

[gregwhitworth]

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.

[josepharhar]

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>)

[annevk]

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