Re: [csswg-drafts] Styling form control pickers (#10440)

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

-- 
GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10440#issuecomment-2276231894 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 8 August 2024 16:34:28 UTC