[selectors] Add :open or :top-layer pseudo class

[mfreed7]

The CSSWG recently resolved to add a :modal pseudo class that applies to elements that are "modal". That was general purpose, in that it should apply to anything that fits the description of being "modal", not just modal <dialog>.

Today, the OpenUI WC similarly resolved to add a :top-layer pseudo class that should apply to (at least) elements using the Popup API which are currently in the top layer. The intention for the naming and behavior, though, was that this pseudo class should also be general purpose. It should match any type of element in the top layer, including modal <dialog>, fullscreen elements, and ::backdrop pseudo elements. Also maybe Shared Element Transitions?

Thoughts?

[SebastianZ]

If :top-layer is meant to be general purpose, should it always match the top-most element in the stacking context?

Also, ::backdrop literally says that it is behind something, so I believe it shouldn't fall into that category.

Sebastian

[Loirooriol]

As mentioned in #6965, adding such selector would prevent allowing authors to place elements into the top layer via some CSS property. Or would this only match elements placed in the top layer by the UA?

::backdrop pseudo elements

:top-layer is like *:top-layer where * matches elements, not pseudo-elements like ::backdrop. Do you mean ::backdrop:top-layer should match? But that's strange, because pseudo-elements can only be followed by user action pseudo-classes (https://drafts.csswg.org/selectors/#pseudo-element-states) and it seems pointless since ::backdrop only generates boxes if the originating element is in the top layer.

[nt1m]

I don't like the name :top-layer because the top layer is an implementation detail. Developers should not know about such detail. A semantic name would be more appropriate.

[plinss]

:top-layer is also confusingly named as there can apparently be multiple 'top-layer's. Sometimes you need to know if an element is in a top-layer vs the top-most top-layer.

[mfreed7]

:top-layer is like *:top-layer where * matches elements, not pseudo-elements like ::backdrop. Do you mean ::backdrop:top-layer should match? But that's strange, because pseudo-elements can only be followed by user action pseudo-classes (https://drafts.csswg.org/selectors/#pseudo-element-states) and it seems pointless since ::backdrop only generates boxes if the originating element is in the top layer.

Sounds like there's generally some pushback to having this apply to ::backdrop pseudo elements, and I can see those points. I agree there's likely not much of a use case, since ::backdrop is always in the top layer. But is there any downside to making ::backdrop match :top-layer, to make it easier to explain? I.e. "anything in the top layer", rather than "anything in the top layer, except for ::backdrop pseudo elements, which are in the top layer but still don't match :top-layer"?

I don't like the name :top-layer because the top layer is an implementation detail. Developers should not know about such detail. A semantic name would be more appropriate.

Suggestions appreciated. Note that in OpenUI, we discussed this multiple times, and there were several suggestions, of which :top-layer won the vote. If there's a better name suggestion, let's discuss. One question though - the "top layer" isn't really an implementation detail, is it? To use it, developers need to know how it works, and it is fairly well specified.

:top-layer is also confusingly named as there can apparently be multiple 'top-layer's. Sometimes you need to know if an element is in a top-layer vs the top-most top-layer.

Yeah, I do think the multiple-top-layer thing is confusing in general. The "top-top-layer", which seems to be just for Shared Element Transitions, should likely get another name and another description. On the other hand, "top layer" is a spec-defined concept and this proposed pseudo class should be tied directly to that definition. Again, name suggestions appreciated.

Side question: what's the use case for "needing to know if an element is in the top-layer vs. the top-most top-layer"?

[KennethHoff]

First ever comment on csswg, but when I read the title, I thought :top-layer somehow referred to the top-most cascade layer.
I think the word layer should maybe be "reserved" only for things relating to cascade layers, as I believe this can cause confusion

[Loirooriol]

is there any downside to making ::backdrop match :top-layer, to make it easier to explain?

::backdrop may match ::backdrop:top-layer, but not :top-layer alone. Just like :hover can only select elements, even if ::before:hover is valid according to the spec. You would need something like **:top-layer from #4565 in order to simultaneously select elements and pseudo-elements.

[SebastianZ]

it seems pointless since ::backdrop only generates boxes if the originating element is in the top layer.

Sounds like there's generally some pushback to having this apply to ::backdrop pseudo elements, and I can see those points. I agree there's likely not much of a use case, since ::backdrop is always in the top layer. But is there any downside to making ::backdrop match :top-layer, to make it easier to explain? I.e. "anything in the top layer", rather than "anything in the top layer, except for ::backdrop pseudo elements, which are in the top layer but still don't match :top-layer"?

While the Fullscreen spec. says that the ::backdrop pseudo-element is in the same top layer as the originating element, from an author's perspective ::backdrop is behind its originating element.

Sebastian

[mfreed7]

I think the word layer should maybe be "reserved" only for things relating to cascade layers, as I believe this can cause confusion

I see the point - suggestions appreciated.

::backdrop may match ::backdrop:top-layer, but not :top-layer alone. Just like :hover can only select elements, even if ::before:hover is valid according to the spec. You would need something like **:top-layer from #4565 in order to simultaneously select elements and pseudo-elements.

Right, I agree with this. I guess the confusing part might be if ::backdrop:not(:top-layer) matched the ::backdrop element. Because by definition ::backdrop is in the top layer. Seems like it should therefore match :top-layer, right?

While the Fullscreen spec. says that the ::backdrop pseudo-element is in the same top layer as the originating element, from an author's perspective ::backdrop is behind its originating element.

Right. But as you point out, it is in the top layer. Seems like it would make sense to have it match :top-layer then.

---

I'm not strongly against having :top-layer not match ::backdrop from a use case point of view. I'm more arguing from a point of clarity about what it means to match :top-layer. Maybe there's a clean way to do that though. For the folks arguing against having ::backdrop match :top-layer, how would you define :top-layer? My preferred definition is "matches anything in the top layer".

[SebastianZ]

While the Fullscreen spec. says that the ::backdrop pseudo-element is in the same top layer as the originating element, from an author's perspective ::backdrop is behind its originating element.

Right. But as you point out, it is in the top layer. Seems like it would make sense to have it match :top-layer then.

I guess, my question is, why does the Fullscreen spec. define that ::backdrop is in the top layer? And that the top layer can consist of multiple elements.

Sebastian

[nt1m]

While the Fullscreen spec. says that the ::backdrop pseudo-element is in the same top layer as the originating element, from an author's perspective ::backdrop is behind its originating element.

Right. But as you point out, it is in the top layer. Seems like it would make sense to have it match :top-layer then.

I guess, my question is, why does the Fullscreen spec. define that ::backdrop is in the top layer? And that the top layer can consist of multiple elements.

Sebastian

This is to prevent a random element outside the top layer with z-index: 999999 to appear above a ::backdrop.

[mfreed7]

This is to prevent a random element outside the top layer with z-index: 999999 to appear above a ::backdrop.

Right, or if you have nested popups/dialogs. The backdrop from the topmost dialog should be on top of the other (non-topmost) dialog.

[mfreed7]

And that the top layer can consist of multiple elements.

Nested elements is the answer here too. It's a semi-common use case. Like a dialog that has a tooltip on top. Both are in the top layer.

[nt1m]

the "top layer" isn't really an implementation detail, is it?

I don't think it's a concept that speaks for starters/most people. Web devs know that a certain element is fullscreen, or a certain dialog is open/modal. Blog posts might explain that those things appear on top of all other elements, but without mentioning "top layer". Also, there is the confusion that we had on the WebKit team, on whether an element is a top layer, or is part of a set of elements called "the top layer". I think this pseudo class also has this ambiguity, e.g. :modal means this element is modal, so by the logic :top-layer means: this element is a top layer.

@mfreed7 I think the more important question here is: What use case does this solve for the Popup API?

From what I can understand, we didn't go with something like :popup-open, in case a web developer wants to use a CSS transition to open the popup, where the closed state is not in the top layer, but the open state is. That design seems flawed to me, because I would expect the popup to be in the top layer while the transition is happening (regardless whether it is closing/opening), mainly because pushing/popping the top layer applies a couple of style adjustments, changes the stacking context, containing block, etc. which makes it inefficient to transition (and potentially could end up in broken results with the containing block changing during the transition).
So if the popup is closing, the popup should only be removed from the top layer when the transition for closing is done. If implemented this way, the :top-layer pseudo class would still match even though the popup is closing...

I generally think a :top-layer pseudo class should not exist, and instead the popup API use case should be addressed using something like :popup-open.

[mfreed7]

I don't think it's a concept that speaks for starters/most people. Web devs know that a certain element is fullscreen, or a certain dialog is open/modal. Blog posts might explain that those things appear on top of all other elements, but without mentioning "top layer".

I'm very open to suggestions for a better name.

Also, there is the confusion that we had on the WebKit team, on whether an element is a top layer, or is part of a set of elements called "the top layer". I think this pseudo class also has this ambiguity, e.g. :modal means this element is modal, so by the logic :top-layer means: this element is a top layer.

This is a really great point. My intention was for just the element itself to match :top-layer. I.e.,

<dialog open><div></div></dialog>
<script>
  document.querySelector('dialog').matches(':top-layer'); // true
  document.querySelector('div').matches(':top-layer'); // false
</script>

@mfreed7 I think the more important question here is: What use case does this solve for the Popup API?

From what I can understand, we didn't go with something like :popup-open, in case a web developer wants to use a CSS transition to open the popup, where the closed state is not in the top layer, but the open state is. That design seems flawed to me, because I would expect the popup to be in the top layer while the transition is happening (regardless whether it is closing/opening), mainly because pushing/popping the top layer applies a couple of style adjustments, changes the stacking context, containing block, etc. which makes it inefficient to transition (and potentially could end up in broken results with the containing block changing during the transition). So if the popup is closing, the popup should only be removed from the top layer when the transition for closing is done. If implemented this way, the :top-layer pseudo class would still match even though the popup is closing...

On the general question of how the Popup API will support animations, please see openui/open-ui#335, and in particular, this comment openui/open-ui#335 (comment). TL;DR, the Popup API will have a two-stage update for show/hide, which will allow animations to run after adding, or before removing, a popup from the top layer. As you mentioned, that means :top-layer will match during the transition. But that's actually the point - it is very ergonomic:

[popup] {
  opacity: 0;
  transition: opacity 1s;
}
[popup]:top-layer {
  opacity: 1;
}

I generally think a :top-layer pseudo class should not exist, and instead the popup API use case should be addressed using something like :popup-open.

Certainly just going with :popup-open achieves all of the use cases for the popup API. However, the resolution (#6965 (comment)) for :modal seems to indicate that CSSWG prefers to have more general pseudo classes for concepts. This would be exactly the opposite conclusion.

[nt1m]

On the general question of how the Popup API will support animations, please see openui/open-ui#335, and in particular, this comment openui/open-ui#335 (comment). TL;DR, the Popup API will have a two-stage update for show/hide, which will allow animations to run after adding, or before removing, a popup from the top layer. As you mentioned, that means :top-layer will match during the transition. But that's actually the point - it is very ergonomic:

Your comment seems to suggest otherwise, :top-layer doesn't match during the closing transition, even though the popup is still in the top layer when closing. I think it makes sense for ergonomics, but also is wrong in terms of when the :top-layer pseudo class matches.

Certainly just going with :popup-open achieves all of the use cases for the popup API. However, the resolution (#6965 (comment)) for :modal seems to indicate that CSSWG prefers to have more general pseudo classes for concepts. This would be exactly the opposite conclusion.

I wasn't necessarily fond of the :modal pseudo in the first place (there's still the issue behind it of "what is modal?" or "is fullscreen modal?"), but anyway a modal dialog is a semantic concept well understood by web developers. The top layer is a presentational concept not necessarily well understood, which is the main issue to me.

I'm very open to suggestions for a better name.

:popup-open or just :open seemed like a better name to me, it is quite straightforward to understand. If consistency is an issue, dialog[open] could also be matched to dialog:open (which is useful for dialogs not in the top layer, e.g. non-modal ones).

[SebastianZ]

I guess, my question is, why does the Fullscreen spec. define that ::backdrop is in the top layer? And that the top layer can consist of multiple elements.
Sebastian

This is to prevent a random element outside the top layer with z-index: 999999 to appear above a ::backdrop.

Ok, so it's just a matter of terminology and their paint order defines the actual "layer" they end up in.

My definition would interweave stacking contexts and paint orders, so you'll end up having one layer per element. That means, an element in the top layer is one layer above everything else. A ::backdrop would be one layer below that but still above everything else.
So, regarding your example, the top-layer element would have an imaginary z-index: 1000001; and the backdrop z-index: 1000000;.

And that the top layer can consist of multiple elements.

Nested elements is the answer here too. It's a semi-common use case. Like a dialog that has a tooltip on top. Both are in the top layer.

That's why I meant we'd need multiple top layers. And "top layer" would be defined as above everything that comes before but elements inside this top-layer element can themselves be placed in a new top layer meaning above everything within the top-layer element it's placed in.

(Disclaimer: I didn't read the OpenUI discussions around the Popup API and the top layer yet. So, maybe the concept mentioned in my comments here was already covered earlier.)

Sebastian

[mfreed7]

Your comment seems to suggest otherwise, :top-layer doesn't match during the closing transition, even though the popup is still in the top layer when closing. I think it makes sense for ergonomics, but also is wrong in terms of when the :top-layer pseudo class matches.

Right - for the ergonomics to work, I think :top-layer can't match during show/hide animations, during which the element is still actually in the top layer, but is in the process of animating in or out. That's how the transitions are triggered. I'm open to suggestions here. What's the use case that would break as a result of this "mismatch" during transitions? Do you have suggestions for how to make it cleaner?

I wasn't necessarily fond of the :modal pseudo in the first place (there's still the issue behind it of "what is modal?" or "is fullscreen modal?"), but anyway a modal dialog is a semantic concept well understood by web developers. The top layer is a presentational concept not necessarily well understood, which is the main issue to me.

I'm very open to suggestions for a better name.

I'm still very open to suggestions for a better (general-purpose) name.

:popup-open or just :open seemed like a better name to me, it is quite straightforward to understand. If consistency is an issue, dialog[open] could also be matched to dialog:open (which is useful for dialogs not in the top layer, e.g. non-modal ones).

At OpenUI we discussed :open but decided against it because it was a bit confusing in several cases. See the comments and discussion starting here openui/open-ui#470 (comment).

We can certainly go back to :popup-open, defined for the Popup API only. It just doesn't line up with the resolution for :modal, which is general purpose. If folks are happy with that asymmetry, ok by me.

[bramus]

Flipping things around: What if we had a top-layer pseudo element, i.e. ::top-layer? It would be a pseudo-element that’s only available on the html element.

You wouldn’t use it (or be able) to style the top-layer itself, but could use it to target elements that are inside the top-layer by use of a combinator, e.g.

• ::top-layer * = All elements that appear in the top-layer
• ::top-layer dialog = Only dialog elements that appear in the top-layer

With this, it would also be possible to target the top-most element or even the top-most dialog, as detailed here.

:nth-last-child(1 of ::top-layer dialog) {
  /* topmost modal dialog in the top-layer, yay! */
}

This would require for ::top-layer to report its (virtual) children in the order in which they got added, though. This is info which I suppose is internally already available, because otherwise top-layer wouldn’t be able to stack it’s contents properly.

[css-meeting-bot]

The CSS Working Group just discussed :top-layer pseudo-class.

The full IRC log of that discussion

<fantasai> Topic: :top-layer pseudo-class
<fantasai> github: https://github.com//issues/7319
<fantasai> ????: I've been working on [missed]
<fantasai> ????: We resolved to create :modal, for all things that are modal, starting with modal dialog
<vmpstr> s/????/masonf/
<fantasai> masonf: Raised this issue for what's the pseudo-class for things in the top layer
<fantasai> masonf: We need this so that pop-up can have different styling/animations when it's in the top layer
<fantasai> masonf: There's a bit of a nuance, when animating in or out, will be in top layer but not match the pseudo-class
<fantasai> masonf: so maybe need a pseudo-class that is more specific
<fantasai> masonf: but the question is whether to have such a pseudo-class, and what should it be called
<ntim> q+
<fantasai> masonf: An alternative is to create a top-layer element in HTML, and allow using structural pseudos
<fantasai> masonf: I'm relatively agnostic, thing any of these can work with popup API
<astearns> ack ntim
<fantasai> ntim: I'm quite against the :top-layer pseudo-class, as I mentioned in the issue, I think it doesn't speak to what developers generally want
<fantasai> ntim: For :modal, can describe what :modal is
<fantasai> ntim: But for :top-layer, can't really describe top-layer, doesn't really speak to developer perspective, more of implementer perspective
<fantasai> ntim: I think ?? helps a bit more, but concept of top layer itself is very specific to browser engine worldview
<fantasai> ntim: I don't think it should exist in the current proposed way
<fantasai> ntim: It's also hard to describe what's the relation with the popup API
<fantasai> ntim: Why open popup in the top layer ... it's not straightforward for developers
<fantasai> masonf: You said you're against the whole thing, but your complaint seems to be about the name, is your complaint the name or the concept?
<fantasai> ntim: It's the name, but
<fantasai> ntim: the concept itself is also a hack
<fantasai> ntim: it's a hack by itself
<fantasai> masonf: can you clarify?
<fantasai> masonf: top-layer is well-defined for fullscreen and modal, how is it a hack?
<fantasai> ntim: In a way it's a well-defined concept, sure, but it only exists because there's no way to display everything on top with z-index
<fantasai> ntim: that's the only reason it exists
<fantasai> ntim: it's a hack in that sense, it's a concept that only exists for a certain thing
<masonf> q?
<fantasai> dbaron: Is your objection that you'd rather see separate pseudo-classes for things that put things in the top layer, if there's need for those pseudo-classes?
<fantasai> ntim: yes
<fantasai> astearns: We've had discussion about scoping things to particular UI elements, and wantng to prefer more generic pseudos
<fantasai> ntim: If you want generic pseudo-classes, I think something that speaks more to web developers, something like :open vs :top-layer
<fantasai> ntim: Idk
<fantasai> masonf: Open is also very very overloaded, and can be confusing
<chrishtr> q+
<fantasai> masonf: top-layer is very descriptive, it's either in the top layer or not
<fantasai> masonf: agree it's a hack to get around z-index, but it's well-defined whether it's in top layer or not
<fantasai> masonf: could also create something specific like :open-popup, but if we want to be more generic ...
<astearns> ack chrishtr
<fantasai> chrishtr: Following pattern of :modal class, we want to describe well-defined behaviors, what is the underlying UI state that this is matching against?
<fantasai> chrishtr: In :modal, it's the modalness, can't interact with other things
<fantasai> chrishtr: just need to come up with other names
<fantasai> chrishtr: maybe make specific to the element?
<fantasai> astearns: It's a push me pull you
<fantasai> astearns: making something generic to the property that we're trying to select
<fantasai> astearns: works really well until we really need to distinguish between the two different things that ahve this property that never want to be styled together
<fantasai> astearns: unfortunately we go back and forth quite a bit
<fantasai> chrishtr: if developer wants to do that, they could combine attribute selector with pseudo-classes, to distinguish between different types of the element in the popup state
<fantasai> astearns: that's tru
<astearns> ack fantasai
<TabAtkins> fantasai: Not trying to select the topmost item in the top layer, but all of them, right?
<TabAtkins> masonf: yes
<TabAtkins> fantasai: So if you have multiple dialogs and a popup in there, they're all amtched
<TabAtkins> masonf: Yeah, they're all in there. Suggestion by bramus for a ::top-layer pseudo-el that wuold let you select the top-most one, but as a pseudo-class it gets them all
<bradk> :nth-layer(n) maybe?
<tantek> s/wuold/would
<TabAtkins> fantasai: Okay also there was something about animation state and popups, making this not match? Not sure what that is about.
<TabAtkins> masonf: It's somewhat peripheral, but for popups you can animate it to show or hide. There's two stages - it gets put into the top layer, and need a way to select when it's being shown, and reverse when hidden.
<TabAtkins> masonf: Think that's very specific to the popup api
<TabAtkins> fantasai: Wouldn't you want to do that with the fullscreen or dialog as well?
<TabAtkins> masonf: Yeah might be more general. Let's takl about top-layer first tho, if there's a transitional state we can discuss that
<TabAtkins> fantasai: So it sounds like you want to select top-layer and topmost-layer?
<TabAtkins> masonf: I think it's needed for top layer, but I have heard requests for topmost.
<TabAtkins> fantasai: Okay. I agree top layer isn't ideal term since it's confusable with other things, but we can come up with names.
<TabAtkins> fantasai: First question is just whether we want to add the pseudo at all.
<fantasai> TabAtkins: I might have raised that
<fantasai> TabAtkins: big deal is things that UA puts in top layer, and things that CSS puts in top layer, still want to be distinct
<fantasai> TabAtkins: need to have a discussoin about it
<fantasai> TabAtkins: it's a complicated issue to get the UI right
<fantasai> ??: Are there things CSS can put in the top layer? I think it's just APIs like fullscreen right now
<masonf> https://open-ui.org/components/popup.proposal.alternatives#alternative-css-property
<TabAtkins> s/??/ntim/
<fantasai> astearns: We are at time
<fantasai> astearns: Has OpenUI discussed pseudo-class vs pseudo-element?
<fantasai> masonf: We resolved on pseudo-class :top-layer
<fantasai> astearns: What about pseudo-element?
<fantasai> masonf: can take it back to Open UI
<fantasai> astearns: ok, going to close for today, but can bring it back soon

[mfreed7]

Per the last CSSWG call about this issue, I was tasked with taking this issue back to OpenUI for further discussion. We did that on July 14. See the notes here and my summary and followups here.

The TL/DR is that OpenUI roughly agreed with CSSWG that perhaps :top-layer isn't a good name. We discussed alternatives like :popup-open (specific to the Pop-up API), or just :open (which should apply to other cases like <summary>/<details>). We also discussed the ::top-layer pseudo element suggestion, but found it too non-standard and confusing for developers.

Perhaps we could get this back on the agenda to discuss again? I would propose either :popup-open or :open, but I'd love to hear folks' thoughts.

[plinss]

If we have an :open pseudo-class, it should mean that something is 'open', (and I agree that it should apply to anything that can be open, like <details>). This would have no relation to if it's in the top layer or not (I accept that some things may only be open in the top layer, or may get put in the top layer by virtue of being open, but they are generally orthogonal concepts).

If you want a pseudo-class that means 'in the top layer', I suggest :overlay.

[mfreed7]

If we have an :open pseudo-class, it should mean that something is 'open', (and I agree that it should apply to anything that can be open, like <details>). This would have no relation to if it's in the top layer or not (I accept that some things may only be open in the top layer, or may get put in the top layer by virtue of being open, but they are generally orthogonal concepts).

If you want a pseudo-class that means 'in the top layer', I suggest :overlay.

Right, I think we agree. The idea would be that a pop-up is :open when it’s showing (according to the definition in the explainer). That’s coincidentally when it’s in the top layer, but :open means open. So likely modal dialogs, details/summary, maybe a pop-up select? We’d need to figure out that list.

[mfreed7]

Should it be :open/:closed or should it be :shown/:hidden for symmetry with the API?

Since this is a “general purpose” pseudo class, it seems like open and closed are more generic. Also, “shown” or (particularly) “hidden” could cause confusion of the kind mentioned in the Note with display:none. I.e. something can be in the “open” state but not rendered. That’s still “open”.

[css-meeting-bot]

The CSS Working Group just discussed :open or :top-layer pseudo, and agreed to the following:

• RESOLVED: Accept :open and :closed with definitions as proposed by TabAtkins

The full IRC log of that discussion

<fantasai> Topic: :open or :top-layer pseudo
<fantasai> github: https://github.com//issues/7319#issuecomment-1242377579
<fantasai> TabAtkins: We've talked about this topic before, last time we did the name :open seemed to be prefered
<fantasai> TabAtkins: we wanted a strict definition before resolving
<fantasai> TabAtkins: so I drafted one, see comment
<fantasai> TabAtkins: [reads comment]
<fantasai> TabAtkins: secondary question, do we want a :closed pseudo-element
<fantasai> TabAtkins: because :not(:open) selects all elements not just openable
<fantasai> TabAtkins: First question is, should we resolve to add :open with this definition?
<tantek> SGTM and +1 to :closed
<masonf> q?
<flackr> +1 to both
<fantasai> TabAtkins: second, do we want to add :closed
<fantasai> +1 to both
<Rossen_> q?
<masonf> +1 to both
<fantasai> Rossen_: +1 to both
<fantasai> TabAtkins: There's also a comment from annevk about asking ":shown", and masonf replied that it would be less confusing to use :open
<masonf> q+
<PaulG> +1 to both
<ydaniv> how will :closed match differently from :not(:open)?
<fantasai> TabAtkins: I agree with masonf's comment
<tantek> agreed, open/closed sound more semantic than shown/hidden. also "hidden" already has a different meaning in CSS
<flackr> +1
<fantasai> [see https://github.com//issues/7319#issuecomment-1274745594 ]
<fantasai> plinss: [something JavaScript]
<fantasai> TabAtkins: Only elements that have a notion of open and closed can match :closed
<fantasai> TabAtkins: similar to :playing :paused, can only match elements that have that notion
<fantasai> Rossen_: anything else?
<plinss> s/[something JavaScript]/:open also matches the .open property
<fantasai> Rossen_: objections?
<fantasai> RESOLVED: Accept :open and :closed with definitions as proposed by TabAtkins

[ariarzer]

Why it is open and closed, but not opened and closed ?

I realised that it looks ok from the point of view of the language language view, but it doesn't from the non-native speakers view.

[KennethHoff]

Why is it open and closed, but not opened and closed?

You say The door is open and The door is closed. It's weird, but that's English for you.

I have opened the door, so the door is open & I have closed the door, so the door is closed

opened refers to the act of having completed the action of opening the door, while open is the state of the door after the action has been completed

[tabatkins]

Yup, "open"/"closed" is the pair of words describing the state of an object in English. As W3C specs are written in American English, this is the correct term to use.

[fantasai]

Edited and published. https://www.w3.org/TR/selectors/#open-state

[josepharhar]

FYI I am speccing this in HTML here: whatwg/html#10126