You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[selectors-4] Should we have :open and :closed? #11039
Here is the justification for having both of them: #7319 (comment)
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.
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.
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.
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
Activity
annevk commentedon Oct 15, 2024
Note in particular that the justification for
:closedis no longer valid with the current HTML PR. We did not want to make:closedonly match things that can be closed as this set of items might change over time.tabatkins commentedon Oct 15, 2024
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 commentedon Oct 28, 2024
I am in favor of removing :closed
css-meeting-bot commentedon Nov 21, 2024
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 commentedon Nov 21, 2024
I didn't type the RESOLVED fast enough before the topic was switched, but we resolved on removing :closed for now and keeping :open
Remove the :closed pseudo-class
Remove the :closed pseudo-class (#11326)
Remove :closed pseudo-class
Remove :closed pseudo-class
Remove :closed pseudo-class
Bug 1935777 [wpt PR 49576] - Remove :closed pseudo-class, a=testonly
Bug 1935777 [wpt PR 49576] - Remove :closed pseudo-class, a=testonly
Bug 1935777 [wpt PR 49576] - Remove :closed pseudo-class, a=testonly
Bug 1935777 [wpt PR 49576] - Remove :closed pseudo-class, a=testonly
svgeesus commentedon Jun 27, 2026
Closed by 9655429