[popup] Top layer pseudo class questions

[mfreed7]

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:

1. 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.
2. 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...?
3. 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 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?

[mfreed7]

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]

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

The full IRC log of that discussion

Topic: [popup] Top layer pseudo class questions
github: https://github.com//issues/557
q?
masonf: I raised an issue with the CSS WG and they came back with a few questions that they'd like us to discuss
masonf: in our issue, a month ago or so, we resolved to have a pseudo element called `:top-layer`
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
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
q?
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
ack dbaron
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
that's an interesting angle
dbaron: I believe that was a pretty strong objection
q+
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
dbaron: I believe Peter was saying that quite strongly
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.
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'
masonf: so something like 'popup-showing' would be more suitable?
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
Also, the current style makes the "show/hide" event a little funky and then you start using "transitionend" etc.
masonf: would also get rid of the problem of being in the top layer vs being isible
+1 it was my sense of plinn's feedback too
Side note:: Can't wait for [popup]::popped :D
dbaron I kind of agree with people's thinking here but not strong enough to raise an objection
d/dbaron/dbaron:
q+
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… 
s/popup-showing and popup-open/the spectrum from :popup-showing to :open/
gregwhitworth: the way I viewed top layer was almost like a state
gregwhitworth: for example, you don't solely select a link because it is hovered
gregwhitworth: so for this, for instance, I might only want to style it _when_ it is in the top layer
ack gregwhitworth
ack bkardell_
q+
:on-top?
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
+q
:in-the-top-layer
bkardell_: it doesn't feel like a state to me
bkardell_: once it is in the top layer, you would have _something_, maybe not 'top layer'
ack hdv
hdv: one thing that i found confusing, the proposal for pseudo class is usually applied to an element
hdv: while pseudo classes wouldn't be a state but it wouldn't really be an element either
hdv: either way, we would end up with something that is the same in CSS
masonf: are you proposing to make this a psuedo element rather than pseudo class?
hdv: yeah, I don't know if that makes sense
masonf: yeah that is odd
hdv: I do like it but yeah it feels weird
q?
ack vicgutt
vicgutt: wanted to +1 what bkardell_ and hdv said
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?
masonf: that was a discussion in CSSWG too, what would be the use case to find the top most element?
vicgutt: not sure
Having the ability to select does make non-stacking ::backdrop easier to do.
bkardell_: windows are a stack, the top most one usually has different styling
q+
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.
masonf: currently there is no way to select the top most one
ach chrishtr
ack chrishtr
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
s/eb/be
masonf: I suppose it is like bkardell_ says, when you have windows you would maybe have different styles
Instructional overlays
chrishtr: but isn't that covered by being modal?
:focused
[popup]::tippity-top ?
bkardell_: it's like 'the one that has your attention', not necessary modal, it wouldn't restrict you from going to / using the others
q+
ack bkardell_
gregwhitworth: maybe you're just having it focused, that seems like a different scenario than strictly being the top most of top lasyer
s/lasyer/layer
^ I was supporting chrishtr point btw
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
I actually +1 like the blockingElement proposal :)
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?
(for focus-trapping)
masonf: z-index has no effect, it's parallel vectors that all have their own stacking contexts
I know nothing about this blockingElement that you speak of
bkardell_: ok… so they're all parallel, so when you say 'top of top layer' you really mean the one that is active?
masonf: would be the one that was added last
bkardell_: but if it was about windows it would be the one last used
q+
masonf: only way to reorder things in the top layer is to remove and readd
(tangent: blockingElement proposal "needs implementer interest" -- https://github.com/whatwg/html/issues/897)
bkardell_: ok but that wouldn't be something you would do a lot as you would lose state etc
masonf: yes, not unique to popups by the way, also the case for dialogs etc
bkardell_: right, but that's because we only have modals, and modals don't have the concept of a dialog that has a dialog
bkardell_: that's a different kind of thing than two parallel popups
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?
chrishtr: but focused would make sense, right?
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)
Here's a demo managing multiple "popup" where you only want the oldest "popup" to show ::backdrop: https://codepen.io/jh3y/pen/abYBVOQ
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
Proposed resolution: rename :top-layer to :pop-up-showing.
q+
masonf: there is a conversation about why :open is not a good solution… I'll link to the conversation
gregwhitworth: that would be great as that issue already had a bunch of names there
ack gregwhitworth
gregwhitworth: we could try and gt input on those names
ack bk
masonf: previously we wanted to come up with more generic names, it seems that now we are looking actually for more specific names now
ack bkardell_
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
masonf: there is a :modal pseudo class now that is generic and not specific to an element

[mfreed7]

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

1. 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.
2. 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.
3. 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) 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
  and
  /

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

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]

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]

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.