csswg-drafts

csswg-drafts copied to clipboard

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?

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

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.

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.

: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.

: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"?

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

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.

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

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".

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

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.

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.

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.

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.

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 https://github.com/openui/open-ui/issues/335, and in particular, this comment https://github.com/openui/open-ui/issues/335#issuecomment-1130572590. 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 (https://github.com/w3c/csswg-drafts/issues/6965#issuecomment-1118033655) for :modal seems to indicate that CSSWG prefers to have more general pseudo classes for concepts. This would be exactly the opposite conclusion.

On the general question of how the Popup API will support animations, please see https://github.com/openui/open-ui/issues/335, and in particular, this comment https://github.com/openui/open-ui/issues/335#issuecomment-1130572590. 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 (https://github.com/w3c/csswg-drafts/issues/6965#issuecomment-1118033655) 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).

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

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 https://github.com/openui/open-ui/issues/470#issuecomment-1099537467.

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.

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.

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/w3c/csswg-drafts/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

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.

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.

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.

I like :open, it could also be used for details/dialog/select/etc. Also covers the desire of finding something generic

It’s not explicitly forbidden in the spec just yet, but if :has() were to accept the ::backdrop pseudo, :open would make sense

• :open = open elements
• :open:has(::backdrop) = open elements that have a backdrop, i.e. in the top-layer

Or are there top layered elements that do not have a backdrop? :fullscreen is the only one I can think of?

Or are there top layered elements that do not have a backdrop? :fullscreen is the only one I can think of?

fullscreen elements do have a backdrop, it's just fully covered by the element given its UA styles.

🤦‍♂️ Ah yeah, should’ve checked the spec – https://fullscreen.spec.whatwg.org/#::backdrop-pseudo-element

I'm hoping we can discuss this at the next CSSWG call. It sounds like we might be approaching a consensus on the thread to use :open as the pseudo selector for the pop-up API (when a pop-up is showing), and also have it match both <dialog open>, and <details open>.

Hmmm, while I don't like bikeshedding forever, I think I can be pretty happy with :open. Seems like it hits a clear and reasonably obvious semantic, and applying to both dialog and popup satisfies my "don't use a generic name for a single thing" objection.

The only other thing in the platform I can imagine being "open" might be a select with a dropdown - thoughts? (I don't have an opinion on whether this matches or not.)

Hmmm, while I don't like bikeshedding forever, I think I can be pretty happy with :open. Seems like it hits a clear and reasonably obvious semantic, and applying to both dialog and popup satisfies my "don't use a generic name for a single thing" objection.

Thanks for the +1!

The only other thing in the platform I can imagine being "open" might be a select with a dropdown - thoughts? (I don't have an opinion on whether this matches or not.)

Makes sense to me. There's this issue for <select>: https://github.com/w3c/csswg-drafts/issues/7422. Just pointing it out, since it is (somewhat?) orthogonal to :open, since it matches <select> that will show a dropdown, even when that dropdown isn't "open". So maybe they're useful together?