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

josepharhar has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-ui] Should `::picker(select)` match `:popover-open`? ==
We resolved here to make `::picker(select)` be a part-like pseudo-element here: https://github.com/w3c/csswg-drafts/issues/10758

However, there were questions about whether we should make it match `:popover-open`.

I believe that since `::picker(select)` is a part-like pseudo-element, it should match `:popover-open`.

Here are some reasons I understood were brought up that it shouldn't match `:popover-open` with my counterarguments:
- There shouldn't be more than one way to detect this state in CSS, so we should use `select:open` instead of `::picker(select):popover-open`.
  - I think it's totally fine for us to provide both, and it's beneficial to authors because if we don't support one of the two then authors might just write code that doesn't work and give up without knowing there is another way to do it. @emilio may have also mentioned that there are other use cases in CSS where there are more than one way to do something?
- Allowing `:popover-open` to be matched reveals internal implementation details of `<select>`.
  - I think this is fine because I am putting in the HTML spec that `::picker(select)` is a popover, so any spec-abiding implementation must make this work. I'm sure that other uses of part-like pseudo-elements must reveal other sorts of internal implementation details about the element they match like this, so why should this one be disallowed? I'd like to try giving an example of this but I'm not up to speed on the other proposed or completed usages of part-like pseudo-elements.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10775 using your GitHub account


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

Received on Friday, 23 August 2024 20:55:57 UTC