[css-ui] New value(s) for the appearance property to support <select> stylability

[josepharhar]

In this issue, we have been discussing adding one or more new values to the appearance property to make an interoperable and stylable rendering of <select>, and potentially other elements in the future: #5998

Some possibilities:

1. Add appearance:base-select (or another name) for this, and add additional values as needed for other elements.
   • We could also add more modes for <select>, such as appearance:base-select-excluding-picker.
   • If we get to making a stylable interoperable version of <select multiple>, it could also use base-select or another new name.
2. Add appearance:base and make the interoperable and stylable mode for all form control elements use this.
   • This has potential forward compat issues when people apply it to elements which aren't supported yet.
   • This doesn't seem to support the appearance:base-select-excluding-picker use case.

I don't think it's possible to make all form control elements have an interoperable and stylable appearance:base mode before we ship anything because it could take decades to do this for each element.

We can also add appearance:base later if we make all form control elements have a base-something mode, but I'm not sure if this really makes sense given the appearance:base-select-excluding-picker use case.

[nt1m]

Related issue: #10332, I think it would be worth figuring out how to also bring the extended <select> stylability to appearance: none at least.

I don't think it's possible to make all form control elements have an interoperable and stylable appearance:base mode before we ship anything because it could take decades to do this for each element.

I don't think appearance: base is about enabling stylability. If seen that way, it could indeed take a long time until appearance: base is shippable for all elements in a stable manner. The way I see it at least,appearance: base is only about providing interoperable base styles to controls that authors can work from, not about enabling new pseudo-elements / markup to be used from form controls. This would be a lot faster to do for all controls at once.

This doesn't seem to support the appearance:base-select-excluding-picker use case.

I'm not sure I agree with the design of this, but either way, it's not impossible to support this in the future through a longhand property:

appearance-picker: auto/base or something. I don't see this as preventing the use of the base keyword directly.

[tabatkins]

Recall that the discussion in the joint meeting was that we could always add base later, after we'd gotten all the current controls figured out, and just define that it behaves as the appropriate value depending on the element (or none or auto, if there's no more specific value).

That way we get:

• the forward-compatibility benefits immediately, without delaying at all
• an established structure for other variants, like what Anne mentioned for a select-without-picker mode
• an easy way to verify that a given element's base styling exists (by doing a supports query for the specific value)

This isn't new ground we're treading; we used essentially the same reasoning to settle on reading-order-items having layout-specific keywords, rather than a generic one that could work on everything.