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

mfreed7 · 2022-05-26T23:00:17Z

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?

The text was updated successfully, but these errors were encountered:

SebastianZ · 2022-05-27T21:30:40Z

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 · 2022-05-27T22:05:02Z

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 · 2022-05-28T17:06:27Z

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 · 2022-05-28T17:19:36Z

: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 · 2022-05-31T17:22:48Z

: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 · 2022-05-31T21:12:56Z

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 · 2022-05-31T21:56:06Z

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 · 2022-05-31T22:14:06Z

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 · 2022-06-01T18:25:02Z

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 · 2022-06-01T19:06:41Z

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 · 2022-06-01T19:42:40Z

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 · 2022-06-01T20:23:24Z

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 · 2022-06-01T20:25:05Z

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 · 2022-06-01T20:26:15Z

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 · 2022-06-01T22:33:37Z

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 · 2022-06-02T05:29:00Z

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 · 2022-06-02T11:00:42Z

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 · 2022-06-03T20:53:52Z

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 · 2022-06-28T10:20:25Z

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 · 2022-06-29T17:02:43Z

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 · 2022-07-22T23:21:47Z

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 · 2022-07-23T01:00:41Z

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 · 2022-07-23T02:33:12Z

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.

ariarzer · 2022-10-13T17:21:33Z

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 · 2022-10-13T18:10:25Z

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

The CSSWG just resolved [1] to add an `:open` pseudo class, which is for many things, but pop-up is one of them. This CL replaces `:top-layer` with `:open` everywhere. [1] w3c/csswg-drafts#7319 (comment) Bug: 1307772 Fixed: 1356645 Change-Id: Ie399712952f549108413878fb31a8077e730f218 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3854979 Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1039324} NOKEYCHECK=True GitOrigin-RevId: bf52faea8d868f8a933444d1cfa06c8f4c23b48d

tabatkins · 2022-10-18T17:51:33Z

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.

Per the [1] resolution, the CSSWG will be adding both :open (which is already implemented for pop-up) and :closed (which this CL adds). At this point, both `:open` and `:closed` are only supported for the pop-up API, and only with the HTMLPopupAttribute feature enabled. More general support for other elements will be added later. [1] w3c/csswg-drafts#7319 (comment) Bug: 1307772 Change-Id: If0c27f1f8c7a30fc00656d5eeafe4b6c21bba890

Per the [1] resolution, the CSSWG will be adding both :open (which is already implemented for pop-up) and :closed (which this CL adds). At this point, both `:open` and `:closed` are only supported for the pop-up API, and only with the HTMLPopupAttribute feature enabled. More general support for other elements will be added later. [1] w3c/csswg-drafts#7319 (comment) Bug: 1307772 Change-Id: If0c27f1f8c7a30fc00656d5eeafe4b6c21bba890 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3961537 Reviewed-by: Joey Arhar <jarhar@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1063120}

Per the [1] resolution, the CSSWG will be adding both :open (which is already implemented for pop-up) and :closed (which this CL adds). At this point, both `:open` and `:closed` are only supported for the pop-up API, and only with the HTMLPopupAttribute feature enabled. More general support for other elements will be added later. [1] w3c/csswg-drafts#7319 (comment) Bug: 1307772 Change-Id: If0c27f1f8c7a30fc00656d5eeafe4b6c21bba890 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3961537 Reviewed-by: Joey Arhar <jarhar@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1063120}

fantasai · 2022-11-11T04:07:00Z

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

… API only, a=testonly Automatic update from web-platform-tests Add :closed pseudo class, for the pop-up API only Per the [1] resolution, the CSSWG will be adding both :open (which is already implemented for pop-up) and :closed (which this CL adds). At this point, both `:open` and `:closed` are only supported for the pop-up API, and only with the HTMLPopupAttribute feature enabled. More general support for other elements will be added later. [1] w3c/csswg-drafts#7319 (comment) Bug: 1307772 Change-Id: If0c27f1f8c7a30fc00656d5eeafe4b6c21bba890 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3961537 Reviewed-by: Joey Arhar <jarhar@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1063120} -- wpt-commits: 44ae1c47d984e7e0895f15be90094477783c6fba wpt-pr: 36555

josepharhar · 2024-02-09T20:10:07Z

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

josepharhar · 2024-10-15T18:10:53Z

I opened a new issue about :closed because this doesn't have consensus yet: #11039

mfreed7 mentioned this issue May 26, 2022

[Popup] How should the "popup is top layer" CSS pseudo class behave, and what should it be called openui/open-ui#470

Closed

mfreed7 mentioned this issue Jun 1, 2022

[css-position-4] Define "top layer" positioning scheme #4998

Open

css-meeting-bot mentioned this issue Jun 2, 2022

[Popup] Supporting transitions and animations on open and dismiss openui/open-ui#335

Closed

chrishtr added the Agenda+ label Jun 9, 2022

mfreed7 mentioned this issue Jun 29, 2022

[popup] Top layer pseudo class questions openui/open-ui#557

Closed

astearns removed the Agenda+ label Jun 29, 2022

kbrilla mentioned this issue Jul 5, 2022

overlays - The Popup API, CSS Anchor Positioning, :modal pseudoclass - for Interop 2023 web-platform-tests/interop#93

Closed

mfreed7 mentioned this issue Oct 14, 2022

Add beforeopen, afteropen, beforeclosed, and afterclosed events? whatwg/html#8386

Closed

chromium-wpt-export-bot mentioned this issue Oct 19, 2022

Add :closed pseudo class, for the pop-up API only web-platform-tests/wpt#36555

Merged

fantasai added selectors-4 Current Work Closed Accepted by CSSWG Resolution Needs Edits labels Nov 11, 2022

fantasai added a commit that referenced this issue Nov 11, 2022

[selectors-4] Add :open and :closed pseudo-classes #7319

7dc6e0d

fantasai removed the Needs Edits label Nov 11, 2022

fantasai closed this as completed Nov 11, 2022

jakearchibald pushed a commit to jakearchibald/csswg-drafts that referenced this issue Jan 16, 2023

[selectors-4] Add :open and :closed pseudo-classes w3c#7319

f2ac5de

This was referenced Mar 21, 2023

Is it ok for popover to claim general names like :open and :closed? whatwg/html#9055

Closed

Add element.popoverOpen whatwg/html#9054

Closed

mfreed7 mentioned this issue Mar 23, 2023

[selectors-4] Introduce :popover-open pseudo class #8637

Open

mayank99 mentioned this issue Jun 19, 2024

[css-positioning] position: popover proposal #5699

Open

rejhgadellaa mentioned this issue Sep 27, 2024

Add ::top-layer pseudo element #10963

Open

josepharhar mentioned this issue Oct 15, 2024

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

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

mfreed7 commented May 26, 2022

SebastianZ commented May 27, 2022

Loirooriol commented May 27, 2022

nt1m commented May 28, 2022 •

edited

Loading

plinss commented May 28, 2022

mfreed7 commented May 31, 2022

KennethHoff commented May 31, 2022

Loirooriol commented May 31, 2022

SebastianZ commented May 31, 2022

mfreed7 commented Jun 1, 2022

SebastianZ commented Jun 1, 2022 •

edited

Loading

nt1m commented Jun 1, 2022 •

edited

Loading

mfreed7 commented Jun 1, 2022

mfreed7 commented Jun 1, 2022

nt1m commented Jun 1, 2022

mfreed7 commented Jun 1, 2022

nt1m commented Jun 2, 2022

SebastianZ commented Jun 2, 2022

mfreed7 commented Jun 3, 2022

bramus commented Jun 28, 2022

css-meeting-bot commented Jun 29, 2022

mfreed7 commented Jul 22, 2022

plinss commented Jul 23, 2022

mfreed7 commented Jul 23, 2022

ariarzer commented Oct 13, 2022

KennethHoff commented Oct 13, 2022

tabatkins commented Oct 18, 2022

fantasai commented Nov 11, 2022

josepharhar commented Feb 9, 2024

josepharhar commented Oct 15, 2024

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

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

Comments

mfreed7 commented May 26, 2022

SebastianZ commented May 27, 2022

Loirooriol commented May 27, 2022

nt1m commented May 28, 2022 • edited Loading

plinss commented May 28, 2022

mfreed7 commented May 31, 2022

KennethHoff commented May 31, 2022

Loirooriol commented May 31, 2022

SebastianZ commented May 31, 2022

mfreed7 commented Jun 1, 2022

SebastianZ commented Jun 1, 2022 • edited Loading

nt1m commented Jun 1, 2022 • edited Loading

mfreed7 commented Jun 1, 2022

mfreed7 commented Jun 1, 2022

nt1m commented Jun 1, 2022

mfreed7 commented Jun 1, 2022

nt1m commented Jun 2, 2022

SebastianZ commented Jun 2, 2022

mfreed7 commented Jun 3, 2022

bramus commented Jun 28, 2022

css-meeting-bot commented Jun 29, 2022

mfreed7 commented Jul 22, 2022

plinss commented Jul 23, 2022

mfreed7 commented Jul 23, 2022

ariarzer commented Oct 13, 2022

KennethHoff commented Oct 13, 2022

tabatkins commented Oct 18, 2022

fantasai commented Nov 11, 2022

josepharhar commented Feb 9, 2024

josepharhar commented Oct 15, 2024

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

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

nt1m commented May 28, 2022 •

edited

Loading

SebastianZ commented Jun 1, 2022 •

edited

Loading

nt1m commented Jun 1, 2022 •

edited

Loading