-
Notifications
You must be signed in to change notification settings - Fork 679
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[selectors] Add :open
or :top-layer
pseudo class
#7319
Comments
If Also, 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?
|
I don't like the name |
|
Sounds like there's generally some pushback to having this apply to
Suggestions appreciated. Note that in OpenUI, we discussed this multiple times, and there were several suggestions, of which
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 |
|
While the Fullscreen spec. says that the Sebastian |
I see the point - suggestions appreciated.
Right, I agree with this. I guess the confusing part might be if
Right. But as you point out, it is in the top layer. Seems like it would make sense to have it match I'm not strongly against having |
I guess, my question is, why does the Fullscreen spec. define that Sebastian |
This is to prevent a random element outside the top layer with z-index: 999999 to appear above a |
Right, or if you have nested popups/dialogs. The backdrop from the topmost dialog should be on top of the other (non-topmost) dialog. |
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. |
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. @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 I generally think a |
I'm very open to suggestions for a better name.
This is a really great point. My intention was for just the element itself to match <dialog open><div></div></dialog>
<script>
document.querySelector('dialog').matches(':top-layer'); // true
document.querySelector('div').matches(':top-layer'); // false
</script>
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 [popup] {
opacity: 0;
transition: opacity 1s;
}
[popup]:top-layer {
opacity: 1;
}
Certainly just going with |
Your comment seems to suggest otherwise,
I wasn't necessarily fond of the
|
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
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 |
Right - for the ergonomics to work, I think
I'm still very open to suggestions for a better (general-purpose) name.
At OpenUI we discussed We can certainly go back to |
Flipping things around: What if we had a top-layer pseudo element, i.e. 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.
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 |
The CSS Working Group just discussed 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 |
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 Perhaps we could get this back on the agenda to discuss again? I would propose either |
If we have an If you want a pseudo-class that means 'in the top layer', I suggest |
Right, I think we agree. The idea would be that a pop-up is |
Why it is 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. |
You say
|
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 <[email protected]> Auto-Submit: Mason Freed <[email protected]> Reviewed-by: David Baron <[email protected]> Cr-Commit-Position: refs/heads/main@{#1039324} NOKEYCHECK=True GitOrigin-RevId: bf52faea8d868f8a933444d1cfa06c8f4c23b48d
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
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 <[email protected]> Commit-Queue: Mason Freed <[email protected]> Auto-Submit: Mason Freed <[email protected]> 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 <[email protected]> Commit-Queue: Mason Freed <[email protected]> Auto-Submit: Mason Freed <[email protected]> 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 <[email protected]> Commit-Queue: Mason Freed <[email protected]> Auto-Submit: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1063120}
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 <[email protected]> Commit-Queue: Mason Freed <[email protected]> Auto-Submit: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1063120} -- wpt-commits: 44ae1c47d984e7e0895f15be90094477783c6fba wpt-pr: 36555
… 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 <[email protected]> Commit-Queue: Mason Freed <[email protected]> Auto-Submit: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1063120} -- wpt-commits: 44ae1c47d984e7e0895f15be90094477783c6fba wpt-pr: 36555
FYI I am speccing this in HTML here: whatwg/html#10126 |
I opened a new issue about :closed because this doesn't have consensus yet: #11039 |
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: