Re: [csswg-drafts] [css-forms-1] Should `::picker(select)` match `:popover-open`? (#10775)

> I could live with defining the picker as a magic div that doesn't have a popover attribute and doesn't match :popover-open but somehow is a popover, but that seems kinda silly tbh?

Same and agreed. As I said [in my earlier comment](https://github.com/w3c/csswg-drafts/issues/10775#issuecomment-2329778342), the *whole point* of this `base` appearance stuff is to give authors a dependable, predictable styling structure. Because behavior is involved here, too, that naturally folds into the same reasoning: the fact that a base-select is (or isn't) using `popover` *is part of the exposed behavior contract*, and should be well-specified and consistent across browsers. Because popovers have observable side-effects (like responding to *other* popovers), we *cannot* change the behavior to some future similar feature, at least not without the future similar feature intentionally maintaining heavy back-compat in enough ways that it doesn't matter that it's something new.

So if we use popover, we're stuck with popover. If we're stuck with popover, we should expose that it's a popover, in the normal way that popovers are exposed in any other usage. We should aim for absolutely minimal difference from the author-facing API as much as possible. If we want to change to something else in the future, we'll need a switch for that.

On the other hand, if we want to make something *identical to popover except in a few exceptional cases*, we need to define exactly what that magic is, and then we're still stuck with it. At that point we're just defining a new feature that's special-cased to select, and we need to *justify* why it's worth expanding the defined API surface like that, and why we're not exposing this new thing to authors, too.

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


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

Received on Friday, 20 March 2026 22:59:20 UTC