w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.52k stars 673 forks source link

[selectors-4] Should we have :open and :closed? #11039

Open josepharhar opened 1 month ago

josepharhar commented 1 month ago

It was resolved here to have both :open and :closed pseudo-classes: https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-1276473056

@annevk mentioned here that :closed is redundant with :not(:open): https://github.com/WebKit/standards-positions/issues/413#issuecomment-2406663870

Here is the justification for having both of them: https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-1242377579

Should we also talk about adding the corresponding :closed pseudo class? That would avoid the problem that :not(:open) can match anything, including things that don't open or close.

The HTML spec has not been merged yet: https://github.com/whatwg/html/pull/10126

annevk commented 1 month ago

Note in particular that the justification for :closed is no longer valid with the current HTML PR. We did not want to make :closed only match things that can be closed as this set of items might change over time.

tabatkins commented 1 month ago

Okay, if you purposely don't want to hook :closed to the "openability" of an element, then yeah, it's completely redundant with :not(:open) and we probably shouldn't add it.

josepharhar commented 1 month ago

I am in favor of removing :closed

css-meeting-bot commented 1 week ago

The CSS Working Group just discussed [selectors-4] Should we have :open and :closed?.

The full IRC log of that discussion <gregwhitworth> jarhar: I was hoping this will be quick
<brecht_dr> q+
<gregwhitworth> jarhar: I tried to spec the open and closed pseudo classes in HTML that are in CSS and I was informed that they are redundant and remove the :closed pseudo selector
<gregwhitworth> ack brecht_dr
<gregwhitworth> brecht_dr: one benefit of having :closed is you can select a sibling in CSS with that state and you can make that default and only do it on open
<gregwhitworth> brecht_dr: I see some benefit to having this as well and we have this with disabled and almost no one uses enabled
<gregwhitworth> anne: in those cases you can use :not(:open)
<gregwhitworth> anne: if there are controls we might provide a picker; :close would not always match unless there is an open state
<gregwhitworth> anne: at least until we have a better handle on that open is easier and in the scenario where you'll know there is a picker you can do :not(:open)
<gregwhitworth> ack dbaron
<gregwhitworth> dbaron: I think historically CSS has pairs is so that you can distinguish between the ones they apply and those they don't
<gregwhitworth> dbaron: :close only matches things that could be :open
<gregwhitworth> dbaron: could definition could be non-trivial to be defined and as we talk about inputs that "could" have a picker is not a trivial thing and :close would only apply to a picker like "color", "date" would match if they have a picker and they are closed now
<gregwhitworth> q+
<jarhar> gregwhitworth: i feel like david you agreed with anne, you can do that with not
<gregwhitworth> ack gregwhitworth
<masonf> q+
<jarhar> dbaron: with input its harder to do that with not because you need to write input type= and get the selector for type exactly right and then put not open
<gregwhitworth> dbaron: it's harder to do with :not on inputs is you need to get the type attribute correct
<gregwhitworth> anne: I don't think we want to expose which controls have a picker
<masonf> q-
<gregwhitworth> anne: :closed would expose which controls have a picker
<jarhar> q+
<gregwhitworth> tim: the reason that is an issue is that the picker is not set and it may vary
<gregwhitworth> anne: iOS select multiple has a picker vs inline compared with Desktop
<gregwhitworth> ack jarhar
<ntim> ntim: the set of elements that have a picker is not finalized*
<gregwhitworth> jarhar: I really would like to move this forward and I'm fine with removing closed for now, does someone have strong feelings to keep closed right out of the gate
<masonf> proposed resolution: support :open for now, leave :closed for later.
<gregwhitworth> argyle: yeah, it seems obvious to include them and we think :not(:open) is the same then it seems solvable and they should be provided
<gregwhitworth> anne: :closed would only match an element that HAS a picker and that capability may change over time
<gregwhitworth> anne: :open will only match if the picker is shown and that will require a user action
<gregwhitworth> argyle: we can determine that today correct?
<ntim> q+
<gregwhitworth> anne: whether it's web observable or not
<gregwhitworth> argyle: isn't that a pseudo element of picker() making it web observable?
<gregwhitworth> argyle: as someone coming into this we have :open but not :close?
<gregwhitworth> ntim: the main problem here is someone uses :close selector on the web page and we expand the set of things that have pickers then :close will apply to more things with no action
<masonf> q+
<gregwhitworth> ntim: it's a compat hazard and it doesn't require any action for it to apply
<gregwhitworth> ack ntim
<gregwhitworth> argyle: can we teach "closed" to be to :not(:open)
<gregwhitworth> ntim: there is a difference
<gregwhitworth> masonf: this is akin to appearance: base in that there is compat concerns and once we have all the controls that have pickers we may come back and address them?
<gregwhitworth> anne: maybe, we have to figure out the platform "thing"
<gregwhitworth> anne: there was TAG feedback on whether these should be feasible or not
<gregwhitworth> anne: so I think that would be TBD
<gregwhitworth> q?
<gregwhitworth> ack masonf
<jarhar> proposed resolution: remove :closed for now and keep :open
<gregwhitworth> argyle: I'm in agreement with jarhar that sympathises and I'll not blocking it
<masonf> +1
josepharhar commented 1 week ago

I didn't type the RESOLVED fast enough before the topic was switched, but we resolved on removing :closed for now and keeping :open