[css-ui] How do `appearance: none` and `appearance: auto` render the rich `<select>` markup?

[nt1m]

There's the question of how appearance: none and auto should render the new selects with rich content.

So far, all the demos/prototypes I have seen so far tie the rich select markup to appearance: base-select. However it would feel a bit odd if appearance: none did not show the rich markup, given it would be a violation of the separation of concerns between styling and markup.

appearance: auto may be more of a special case given native frameworks may have restrictions that prevent showing the markup.

Either way, how appearance: none and auto interact with the rich select markup are questions that should be answered, especially as it will pave the way for how appearance generally works even for future controls.

[josepharhar]

However it would feel a bit odd if appearance: none did not show the rich markup

appearance: auto may be more of a special case given native frameworks may have restrictions that prevent showing the markup.

appearance:none and appearance:auto both use the same native or platform-specific picker, so I don’t see how we can make appearance:none switch to using an unrestricted non-native picker without breaking websites which expect to get a native picker. On at least Chromium browsers, this picker exists within a separate OS window that can extend beyond the content area, meaning it cannot contain arbitrary content without creating security issues.

Either way, how appearance: none and auto interact with the rich select markup are questions that should be answered, especially as it will pave the way for how appearance generally works even for future controls.

I figured this would be up to the platform because as you mentioned there are platform-specific restrictions which may prevent showing the markup. Should we really mandate that certain portions of the markup do or don’t get rendered by the native framework?

[nt1m]

appearance:none and appearance:auto both use the same native or platform-specific picker, so I don’t see how we can make appearance:none switch to using an unrestricted non-native picker without breaking websites which expect to get a native picker. On at least Chromium browsers, this picker exists within a separate OS window that can extend beyond the content area, meaning it cannot contain arbitrary content without creating security issues.

I'm curious what is the impact of making explicit appearance: none (e.g. not appearance: auto that falls back to a certain appearance because some properties were set) switch to the same picker that is used by appearance: base, select has appearance: auto by default in UA stylesheets, so I suspect this might be feasible with little compat impact. I suspect very few sites use appearance: none explicitly on the select element.

[josepharhar]

I suspect that appearance:none is used enough on select elements that it would be a breaking change. A quick search shows a few samples on stackoverflow which use appearance:none on select:

• https://stackoverflow.com/questions/39483347/styling-the-select-element-with-appearance-none-css-property
• https://stackoverflow.com/questions/16631801/why-does-using-webkit-appearance-none-on-a-select-option-in-osx-make-the-tex

I'd be happy to add a use counter if you'd like some concrete data.