[popup] Top layer pseudo class questions #557

mfreed7 · 2022-06-29T17:15:27Z

In #470 we resolved to a) have a pseudo class that matches when a pop-up is in the top layer, and b) call it :top-layer.

I raised this issue with the CSSWG, and several points were made:

While a pop-up is animating show/hide, it will be in the top layer, but needs to not match some pseudo class, so that transitions can be triggered from that pseudo class. (See this description of pop-up animation behavior.) This might mean we need an additional pseudo class for the transitional state, which would likely be very specific to pop-up.
There was some discomfort (likely akin to the discussions on #470) with using "top layer" as a name, since it isn't a term web developers are accustomed to using. However, it is the name chosen by the spec to describe it, so...?
Another suggestion was made by @bramus to use a pseudo element instead of a pseudo class. The idea is a ::top-layer element on the <html> element only, which can be used to select things in the top layer:

::top-layer [popup]) {
  /* any pop-up that is in the top-layer */
}
:nth-last-child(1 of ::top-layer [popup]) {
  /* only the topmost pop-up in the top-layer */
}

General thoughts?

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

mfreed7 · 2022-06-29T17:22:24Z

In particular, I should have mentioned, the CSSWG would like us (OpenUI) to discuss the ::top-layer pseudo element approach, and bring our feedback back to CSSWG.

Agenda+ to do that, at least.

css-meeting-bot · 2022-07-14T18:28:34Z

The Open UI Community Group just discussed [popup] Top layer pseudo class questions.

The full IRC log of that discussion

<gregwhitworth> Topic: [popup] Top layer pseudo class questions
<gregwhitworth> github: https://github.com//issues/557
<gregwhitworth> q?
<hdv> masonf: I raised an issue with the CSS WG and they came back with a few questions that they'd like us to discuss
<hdv> masonf: in our issue, a month ago or so, we resolved to have a pseudo element called `:top-layer`
<hdv> masonf: a question I had is if it should apply to other things like full screen… they had some issues, one was with the name, they thought it was confusing and web devs might not be accustomed too or understand , they might call it something else
<hdv> masonf: the other question was around animation behaviors: basically they wanted the ability to put an element in the top layer before the pseudo class applies, so that it can be transitioned/animated
<gregwhitworth> q?
<hdv> masonf: the third question was around: shouldn't instead of a pseudo class :top-layer we should have a ::top-layer pseudo element, so that you have more matching abilities including finding the top most element
<gregwhitworth> ack dbaron
<hdv> dbaron: maybe I should add… a few people in the CSSWG would be very uncomfortable with a pseudo class that is addressing being in the top layer, rather than pseudo class that addresses things that put things in the top layer
<gregwhitworth> that's an interesting angle
<hdv> dbaron: I believe that was a pretty strong objection
<gregwhitworth> q+
<hdv> dbaron: my sense of the discussion was… and could be my own bias as I also prefer it… it would be that pseudoclass select the things that cause things to be in the top layer, rather than the top layer concept itself
<hdv> dbaron: I believe Peter was saying that quite strongly
<jhey> This kinda goes back to the questions of was it worth having ::entering-top-layer and ::exiting-top-layer pseudos. I do still think people will kind of want that :top-layer concept available for layout purposes potentially.
<hdv> dbaron: I dont't think it matters to have popup in the name… it matters whether the underlying concept is 'is the popup is popped up' vs 'is the element in the top layer'
<hdv> masonf: so something like 'popup-showing' would be more suitable?
<hdv> dbaron: popup-showing and popup-open could both work, doing different things, but they both address the popup rather than the being in the top layer aspect
<jhey> Also, the current style makes the "show/hide" event a little funky and then you start using "transitionend" etc.
<hdv> masonf: would also get rid of the problem of being in the top layer vs being isible
<bkardell_> +1 it was my sense of plinn's feedback too
<jhey> Side note:: Can't wait for [popup]::popped :D
<hdv> dbaron I kind of agree with people's thinking here but not strong enough to raise an objection
<hdv> d/dbaron/dbaron:
<bkardell_> q+
<hdv> gregwhitworth: the devs on this call said… well that wasn't the purpose of it and how would we do this for others like accordions…
<dbaron> s/popup-showing and popup-open/the spectrum from :popup-showing to :open/
<hdv> gregwhitworth: the way I viewed top layer was almost like a state
<hdv> gregwhitworth: for example, you don't solely select a link because it is hovered
<hdv> gregwhitworth: so for this, for instance, I might only want to style it _when_ it is in the top layer
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack bkardell_
<hdv> q+
<vmpstr> :on-top?
<hdv> bkardell_: it was also my impression of the feedback that it was strong feedback: that pseudo classes are a state and top layer doesn't really feel like a state… eventhough I hear gregwhitworth's feedback that it kind of is a state
<vicgutt> +q
<masonf> :in-the-top-layer
<hdv> bkardell_: it doesn't feel like a state to me
<hdv> bkardell_: once it is in the top layer, you would have _something_, maybe not 'top layer'
<gregwhitworth> ack hdv
<gregwhitworth> hdv: one thing that i found confusing, the proposal for pseudo class is usually applied to an element
<gregwhitworth> hdv: while pseudo classes wouldn't be a state but it wouldn't really be an element either
<gregwhitworth> hdv: either way, we would end up with something that is the same in CSS
<gregwhitworth> masonf: are you proposing to make this a psuedo element rather than pseudo class?
<gregwhitworth> hdv: yeah, I don't know if that makes sense
<gregwhitworth> masonf: yeah that is odd
<gregwhitworth> hdv: I do like it but yeah it feels weird
<gregwhitworth> q?
<gregwhitworth> ack vicgutt
<hdv> vicgutt: wanted to +1 what bkardell_ and hdv said
<hdv> vicgutt: in the bike shedding phase there was a tweet from Open UI where I replied with ':stack' instead of layer, so that you could have ':stack:first-child' kind of things?
<hdv> masonf: that was a discussion in CSSWG too, what would be the use case to find the top most element?
<hdv> vicgutt: not sure
<jhey> Having the ability to select does make non-stacking ::backdrop easier to do.
<hdv> bkardell_: windows are a stack, the top most one usually has different styling
<chrishtr> q+
<jhey> If you have reduced opacity ::backdrop and multiple popup, the ::backdrop will darken because of the overlap. I have a demo for that and you need a little LIFO Array to keep track of it.
<hdv> masonf: currently there is no way to select the top most one
<gregwhitworth> ach chrishtr
<gregwhitworth> ack chrishtr
<hdv> chrishtr: I think the use case is… if the top one is modal, but then :modal would already match that… if you have multiple popups, none of which are modal… not sure what the use case would eb
<hdv> s/eb/be
<hdv> masonf: I suppose it is like bkardell_ says, when you have windows you would maybe have different styles
<jhey> Instructional overlays
<hdv> chrishtr: but isn't that covered by being modal?
<chrishtr> :focused
<scotto_> [popup]::tippity-top ?
<hdv> bkardell_: it's like 'the one that has your attention', not necessary modal, it wouldn't restrict you from going to / using the others
<bkardell_> q+
<gregwhitworth> ack bkardell_
<hdv> gregwhitworth: maybe you're just having it focused, that seems like a different scenario than strictly being the top most of top lasyer
<hdv> s/lasyer/layer
<gregwhitworth> ^ I was supporting chrishtr point btw
<hdv> bkardell_: this goes into some things I'm not clear about in the current design… this has been developing for a long time, even long time ago there was a blocking element proposal even written up in the HTML spec
<Travis> I actually +1 like the blockingElement proposal :)
<hdv> bkardell_: there is the difference between z-index and top-layer, and top-layer can also have z-indexes, but it also has a stack of blocking element, is that correct?
<Travis> (for focus-trapping)
<hdv> masonf: z-index has no effect, it's parallel vectors that all have their own stacking contexts
<gregwhitworth> I know nothing about this blockingElement that you speak of
<hdv> bkardell_: ok… so they're all parallel, so when you say 'top of top layer' you really mean the one that is active?
<hdv> masonf: would be the one that was added last
<hdv> bkardell_: but if it was about windows it would be the one last used
<gregwhitworth> q+
<hdv> masonf: only way to reorder things in the top layer is to remove and readd
<Travis> (tangent: blockingElement proposal "needs implementer interest" -- https://github.com/whatwg/html/issues/897)
<hdv> bkardell_: ok but that wouldn't be something you would do a lot as you would lose state etc
<hdv> masonf: yes, not unique to popups by the way, also the case for dialogs etc
<hdv> bkardell_: right, but that's because we only have modals, and modals don't have the concept of a dialog that has a dialog
<hdv> bkardell_: that's a different kind of thing than two parallel popups
<hdv> bkardell_: so top of the top layer is kind of a nonsense thing? because it's the only thing where this makes sense, but we've just come full circle that it doesn't make sense?
<hdv> chrishtr: but focused would make sense, right?
<hdv> gregwhitworth: it seems like the key thing CSSWG are looking for is either renaming (they don't like the term top layer because that's like a implementation detail)
<jhey> Here's a demo managing multiple "popup" where you only want the oldest "popup" to show ::backdrop: https://codepen.io/jh3y/pen/abYBVOQ
<hdv> masonf: yes seems like the main thing is the name… from the convo here it seems like the name we want is more specific to popup and more specific to the state of showing/opened, and not that it is in the top layer
<masonf> Proposed resolution: rename :top-layer to :pop-up-showing.
<bkardell_> q+
<hdv> masonf: there is a conversation about why :open is not a good solution… I'll link to the conversation
<hdv> gregwhitworth: that would be great as that issue already had a bunch of names there
<gregwhitworth> ack gregwhitworth
<hdv> gregwhitworth: we could try and gt input on those names
<gregwhitworth> ack bk
<hdv> masonf: previously we wanted to come up with more generic names, it seems that now we are looking actually for more specific names now
<gregwhitworth> ack bkardell_
<hdv> bkardell_: the minutes for that discussion about :open are available… there was talk that modalness could be a state, and maybe that does not only apply to a modal dialog, maybe there could be modal popups
<hdv> masonf: there is a :modal pseudo class now that is generic and not specific to an element

mfreed7 · 2022-07-14T19:55:58Z

So from the discussion just now, I heard a few things:

Many people felt that "top layer" isn't a state, or that we need something more related to the "thing that put something into the top layer". That would indicate that we likely need rename from :top-layer to something pop-up related like :pop-up-showing, :popup-open, or just :open. A nice side effect of renaming would be that it resolves the issue about :top-layer not matching pop-ups that are animating.
There wasn't a ton of support for the ::top-layer pseudo element approach. While it had more "power", e.g. to support selecting the topmost top-layer element, it is also very non-standard and hard to understand. A solution more like element:top-layer:topmost would be preferred. This needs more thought. There were a few use cases discussed for needing to select the topmost top-layer element, such as styling the topmost "window" in a windowing system differently from the others.
In terms of naming, I was tasked with linking to the various conversations we've already had about naming :top-layer:

We discussed and resolved on the name of :top-layer in #470. This was discussed live at OpenUI in these meetings: April 14, April 28, May 19. We discussed :open as an idea several times in these meetings and on the issue. In particular, this comment summarizes :top-layer vs. :open.
We had a prior issue (#311) where we decided not to include an open content attribute on the (then) <popup> element. But we also discussed an :open pseudo selector there.

In terms of using :open as the pseudo class indicating that a pop-up is showing, I can only see a few objections:

It is possible to make a pop-up invisible while it is "showing", e.g. via [popup]{display:none}, or visible while it is "hidden", e.g. via [popup]{display:block !important}. That applies to anything though, so perhaps that's not too confusing.
We would need a resolution from CSSWG that :open should apply to all things that can be "open", such as <dialog> and <summary>/<details>. What about other things that don't explicitly have an open attribute, such as a fullscreen element? That's "open", isn't it?
An alternative to the above would be :popup-open which only applies to pop-ups.

Thoughts? Having re-read all of the above discussion, I'm starting to like renaming to either :open or :popup-open.

@gregwhitworth I think this can go back on the agenda next week, if possible.

futekov · 2022-07-16T05:08:34Z

I feel like :topmost or similar is non-scalable in the long term - it's like having :first-child but no :nth-child(). Even if we cannot think of a use case for selecting the other popup layers this doesn't mean that developers won't find one.

A stacking selector like the tree-structural nth-child but for layers (similar to the stacking idea by @VicGUTT) would be in the spirit of existing CSS conventions. Maybe something with an index to allow for a flexible selection of the top (or any other) layer:

:nth-layer-top(1) or :nth-top-layer(1), because :nth-layer(1) seems confusing on whether it's the first created (bottom) or the topmost
:popup-top(1)
:nth-top-popup(1)

mfreed7 · 2022-08-17T20:09:55Z

Since w3c/csswg-drafts#7319 is on the agenda in CSSWG, I'm going to just close this issue and let it get resolved there instead of here.

mfreed7 · 2022-08-24T17:05:55Z

CSSWG just resolved to add :open for "things that are open". That would clearly apply to pop-up, assuming any reasonable definition for "open". As such, I'm going to update the explainer to use :open everywhere it currently uses :top-layer.

mfreed7 added popover The Popover API agenda+ Use this label if you'd like the topic to be added to the meeting agenda labels Jun 29, 2022

gregwhitworth added the CSSWG Issues that have a relationship with CSS label Jul 11, 2022

mfreed7 mentioned this issue Jul 22, 2022

[selectors] Add :open or :top-layer pseudo class w3c/csswg-drafts#7319

Closed

mfreed7 removed the agenda+ Use this label if you'd like the topic to be added to the meeting agenda label Jul 22, 2022

mfreed7 closed this as completed Aug 17, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[popup] Top layer pseudo class questions #557

[popup] Top layer pseudo class questions #557

mfreed7 commented Jun 29, 2022

mfreed7 commented Jun 29, 2022

css-meeting-bot commented Jul 14, 2022

mfreed7 commented Jul 14, 2022

futekov commented Jul 16, 2022

mfreed7 commented Aug 17, 2022

mfreed7 commented Aug 24, 2022

[popup] Top layer pseudo class questions #557

[popup] Top layer pseudo class questions #557

Comments

mfreed7 commented Jun 29, 2022

mfreed7 commented Jun 29, 2022

css-meeting-bot commented Jul 14, 2022

mfreed7 commented Jul 14, 2022

futekov commented Jul 16, 2022

mfreed7 commented Aug 17, 2022

mfreed7 commented Aug 24, 2022