-
Notifications
You must be signed in to change notification settings - Fork 191
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
[Popup] How should the "popup is top layer" CSS pseudo class behave, and what should it be called #470
Comments
It is likely relevant to point out this related issue: w3c/csswg-drafts#6965 That one initially proposes a |
I've renamed the issue, given the resolution not to have a live content attribute, and the need for a way to style based on state. So the questions remain:
See the OP for my views, but I'd love to hear what others think. |
So we just had a discussion at OpenUI, and somehow the minutes didn't get posted. Here is a copy/paste from the IRC. The Open UI Community Group just discussed
The full IRC log of that discussion[11:12] masonf: #470 [11:13] q+ [11:13] * Zakim sees emilio on the speaker queue [11:13] masonf: The bikeshedding what should it be called? 2 other concerns: Should it only apply when the popup is top layer or when it is visible? [11:14] It is possible to have a visible not top layer [11:14] I would not expect it to change the pseudo-class unless it was toggled using its internal functionality. [11:14] masonf: other related question: Should the same pseudo class apply to all modal dialogs? It will seem convenient to have one pseudo class that applies to all of these? [11:14] q+ [11:14] * Zakim sees emilio, bkardell_ on the speaker queue [11:14] q+ for questuib [11:14] * Zakim sees emilio, bkardell_, una on the speaker queue [11:15] q+ [11:15] * Zakim sees emilio, bkardell_, una, dbaron on the speaker queue [11:15] ack emilio [11:15] * Zakim sees bkardell_, una, dbaron on the speaker queue [11:15] masonf: Recap - what should it be called? How should it apply to other things? And should it get other things besides popup? [11:15] q-- [11:15] * Zakim sees bkardell_, una, dbaron on the speaker queue [11:15] * bkardell_ dbaron how do I move to the back of the queue? [11:15] q- [11:15] * Zakim sees una, dbaron on the speaker queue [11:16] q+ [11:16] * Zakim sees una, dbaron, bkardell_ on the speaker queue [11:16] fuschia: You can only make it apply when its in the top layer in the DOM. i.e if it is not visible the pseudo class should not apply [11:16] * dbaron maybe "q- later"? [11:16] * bkardell_ thanks [11:16] q? [11:16] * Zakim sees una, dbaron, bkardell_ on the speaker queue [11:16] una: Is this the same as popup open or is it different? [11:16] * bkardell_ likes that una sounds like she is about to start a ball game [11:16] masonf: This will be the replacement of popup open [11:16] s/fuchsia/emilio (sorry!) [11:16] * bkardell_ "ooohhh say can you seeeeee" [11:17] masonf: We decided before to make a pseudo class [11:17] una: I like the ability to open and close. I feel just 'open' feels like a clear state to pseudo state. [11:17] * dbaron q- since I was just going to ask whether CSS styles that can put things in the top layer, which is subsumed by emilio's comment [11:17] * Zakim dbaron, you typed too many words without commas; I suspect you forgot to start with 'to ...' [11:17] * dbaron q- [11:17] * Zakim sees una, bkardell_ on the speaker queue [11:17] * dbaron ack una [11:18] una, you wanted to discuss questuib [11:18] * Zakim sees bkardell_ on the speaker queue [11:18] == jhey [~jhey@7df9ea9e.public.cloak] has joined #openui [11:18] masonf: I've been considering top layer or not [11:18] I agree with una that `toplayer` is less clear to me than a value like `open` or `shown`. [11:18] una: I do like the idea of having open be the same across those elements (or show). The generic binary state change [11:19] q? [11:19] * Zakim sees bkardell_ on the speaker queue [11:19] * bkardell_ :relevant [11:19] q+ [11:19] * Zakim sees bkardell_, scotto_ on the speaker queue [11:19] In a related thing — If I use `outline: 0`, I still expect `:focus` to apply to an element. [11:20] masonf: I don't think there's a security. Just more of what name communicates the best [11:20] q? [11:20] * Zakim sees bkardell_, scotto_ on the speaker queue [11:20] ack bkardell_ [11:20] * Zakim sees scotto_ on the speaker queue [11:21] bkardell_: summary/details doesn't support an open pseudo class does it? I think about what I'm intending to target and they seem like different things [11:21] == jhey_ [~uid550609@7df9ea9e.public.cloak] has joined #openui [11:21] mkardell: Curious if backdrop is relevant or not as I think it's the only thing that's top layer related [11:21] Personal aside: I kinda wish `` had done something like `:open` instead of `[open]`. [11:22] s/mkardell/bkardell_ [11:22] q+ [11:22] * Zakim sees scotto_, emilio on the speaker queue [11:22] una: There's no backdrop on popup right now? popup will be top layer right? [11:22] masonf: Yes popup will be top layer [11:23] "backdrop" implies the existence of "frontdrop" [11:23] masonf: backdrop is a pseudo element that can populated or styled [11:23] ack scotto_ [11:23] * Zakim sees emilio on the speaker queue [11:23] I'd like to have that discussion (adding backdrop to popup to allow modal popups) [11:23] Modal popups 💯 [11:23] +1 to that backdrop discussion [11:24] emilio: This made me think whatever openPopup does on open dialog should be the same as how full screen modal dialogs interacts [11:24] masonf: That's a good point [11:24] q? [11:24] * Zakim sees emilio on the speaker queue [11:24] ack emilio [11:24] * Zakim sees no one on the speaker queue [11:24] ack emilio [11:24] * Zakim sees no one on the speaker queue [11:24] * una i'll open an issue [11:25] Proposed resolution: The pseudo state should only apply when the popup is in the top layer, unrelated to whether it is visible. [11:25] == jhey [~jhey@7df9ea9e.public.cloak] has quit [Ping timeout: 180 seconds] [11:25] JonathanNeal: I think there's good discussions and I'm also wondering if the popup itself should have a specific behavior? Would it get a pseudo class at all? [11:25] masonf: We resolved it should get a pseudo class but not whether it should apply to other elements [11:26] +1 to masonf’s proposal [11:26] masonf: The pseudo state should apply to the top layer whether or not it is available [11:26] s/available/visible [11:26] +1 [11:26] +1 :-) [11:27] +1 [11:27] 👍 [11:27] RESOLVED: The pseudo state should only apply when the popup is in the top layer, unrelated to whether it is visible. [11:27] JonathanNeal: I think we have resolution there with the plus ones [11:27] Topic: Explainer is missing imperative API for anchor and popup attributes |
So the resolution above checks one of the questions off the list: the pseudo class can only apply when the popup is in the top layer, and cannot be related to actual visibility. Good. That leaves two open questions from the prior list, plus another nuance was added to the last point. So here's the current set of open questions to discuss:
So essentially, the open question becomes: "top layer" or "open"? Remember, in both cases, the pseudo class cannot be related to actual visibility, but only to the UA's concept of either being in the top layer, or being "open". |
Looks like the CSSWG is moving towards resolving that each top layer "concept" needs its own pseudo class. I.e. no "general purpose" name for a pseudo class that means "any element in the top layer". Assuming that resolution happens as expected, that effectively resolves the last two bullet points in my comment above, and this issue becomes a bikeshed on just the name we should use for when a popup is in the top layer. I propose Other ideas? |
What about |
If this were a "general purpose" top layer pseudo class, I think I'd like |
The Open UI Community Group just discussed
The full IRC log of that discussion<hdv> Topic: [Popup] How should the "popup is top layer" CSS pseudo class behave, and what should it be called #470<hdv> github: https://github.com//issues/470 <hdv> masonf: we resolved to create a pseudo class that matches when the popup is in the top layer, (showing/open) <hdv> masonf: there is an active issue in the CSSWG for modal dialog, it looks like they may resolve to using a :modal pseudo class <hdv> masonf: if that applies to popup, we should not use :modal because they are not necessarily modal <JonathanNeal> q+ <flackr> q+ <una> q+ <bkardell_> q+ <hdv> masonf: do we want to go with something specific to popup because easy to understand for developers? or not? <hdv> ack Jona <masonf> The CSSWG issue: https://github.com/w3c/csswg-drafts/issues/6965 <hdv> JonathanNeal: would you clarify whether that pseudo was a pseudo class or pseudo element? <hdv> masonf: both are pseudo classes, they are not elements, they are states <hdv> flackr: I was in the CSSWG discussion, it sounded like there was reasonable support for these generic types of pseudo classes <hdv> flackr: i like the name overlay… my take on the other meeting that other people would agree to overlay for anything in the top layer <hdv> q? <hdv> ack flack <hdv> ack una <hdv> una: I also like something a little more generic, like overlay <hdv> una: I don't know if I necessarily like 'toplayer' as a pseudo class, like you could have multiple things in the top layer <JonathanNeal> q? <hdv> flackr: if we have a better definition of what an overlaytop layer is we would not have the naming confusion? <hdv> masonf: in general, whatever what we call it, it has to mean exactly one thing, that the element is in the top layer… we'll have to define it as that, and not anything else <hdv> una: I think that toplayer is a lot more clear than overlay, because overlay could even be a name for a type of component… but a dialog could also be in toplayer, so would this be reusable between dialogs and other things? <hdv> masonf: yes <hdv> una: in that case do we need the modal pseudo class? <hdv> masonf: I don't want to derail the csswg train that is going towards modal <hdv> masonf: toplayer or modal… could go either way… <hdv> ack bkardell_ <JonathanNeal> ack bkardell_ <hdv> bkardell_: I wanted to add… read the minutes of the csswg… the key pushback observation was from Peter Linz… these are states, but these are more like a few independent states? <hdv> bkardell_: so we should probably gear our thinking towards that <flackr> +1 <hdv> bkardell_: eventhough modal matches the modal dialog today, it would potentially match other things in the future <JonathanNeal> q? <flackr> q+ <hdv> una: it sounds like there is a world where we have modal and popups, and a modal would be a popup with some other attributes to it, like a square and rectangle situation <JonathanNeal> ack flackr <hdv> flackr: the other thing in the minutes… there was a concern with toplayer because it is not always the thing that is on top <bkardell_> * for some definition of layer :) <Alexander_Futekov> q+ <hdv> flackr: there is a risk of confusion there <hdv> Alexander_Futekov: what if we use something very generic like :open? that can be reused for many other elements in the future? <hdv> flackr: popup could happen on any element, so a developer might have a hard time styling as it could be on many other things <hdv> masonf: like a details/summary that is also in the top layer and matched too <JonathanNeal> q? <JonathanNeal> ack Alexander_Futekov <masonf> Proposed resolution: we should choose a pseudo class name that a) applies to any element that is *in the top layer*, and b) is therefore named generically and not specifically to popups. <JonathanNeal> +1 to that proposed resolution <flackr> +1 <hdv> +1 <bkardell_> +1 <hdv> miriam: another point of confusion could be… we now also have cascade layers <JonathanNeal> `:toplayaa` :) <hdv> masonf: very good point… I don't know if it is essential that the name contains toplayer at all <hdv> una: as long as it doesn't add confusion <davatron5000> what about a <LAYER> element? <scotto> boo <masonf> RESOLVED: we should choose a pseudo class name that a) applies to any element that is *in the top layer*, and b) is therefore named generically and not specifically to popups. |
So per the resolution, we've decided to pick a generic (non-popup-specific) name that means "this element is in the top layer" (exactly as defined right here). One thing to remember about that definition: there can be multiple elements in the top layer, meaning that an element in the top layer isn't guaranteed to be "on top" of everything. Just guaranteed to be "on top" of everything that isn't in the top layer. Another thing to remember is that because this pseudo class will apply to anything in the top layer, it should match modal Suggestions welcome! The ones I've heard so far:
|
Please vote with emojis! Or suggest something else and I'll add it to the list.
|
Side-note, CSSWG just resolved that |
Reminder: please vote for your favorite top layer pseudo class name, or suggest a new one! We only have two votes at this point. |
The Open UI Community Group just discussed The full IRC log of that discussion<gregwhitworth> Topic: [Popup] How should the "popup is top layer" CSS pseudo class behave, and what should it be called<scotto> giant +1 to not rushing <gregwhitworth> github: https://github.com//issues/470 <hdv> masonf: in the issue there was a vote and there were options… overwhelming winner was `:top-layer` <hdv> masonf: I would propose a resolution that we would call it that <masonf> Proposed resolution: Name the CSS pseudo class for "a popup is in the top layer" to `:top-layer`. <hdv> gregwhitworth: my only issue with it is that top-layer doesn't necessarily mean it is at the top <hdv> gregwhitworth: if I was going to use it I would think it would be at the top most… but I don't want to bikeshed into eternity so wouldn't object to it <bkardell_> :premire-layer <JonathanNeal> q+ <hdv> masonf: same reason to not go for 'top most'… then top layer probably better <gregwhitworth> ack JonathanNeal <hdv> JonathanNeal: since you brought it up… the voting is not overwhelmingly top layer anymore <hdv> masonf: we can also wait a little longer… <hdv> gregwhitworth: for clarification… top layer is in the top most composited layer, but it may not be in paint order on top? <hdv> gregwhitworth: or would there be layers on top of the top layer? <hdv> masonf: no <JonathanNeal> so its generally “over” other layers. :P <hdv> masonf: but within that top layer things are painted in different order <hdv> [ +1 to ask more attention, I will go and tweet myself ] <masonf> Proposed resolution: we will give voting another week and resolve next week. <bkardell_> :not-the-droids-you-are-looking-for-layer <hdv> gregwhitworth: can we agree to resolve next week? |
Per the meeting just now, please vote! As a quick reminder, the definition for this pseudo class will be: "this element is in the top layer, exactly as defined right here". We will resolve on a name next week. |
Copying the link to my response on Twitter where I suggested ":layer-stack" as really, all I could think of while reading this issue is "stacks", "stacking". https://twitter.com/VictorGutt/status/1527770596871921669?t=K4J82G2d-1lkfBtUub0j0w&s=19 |
The Open UI Community Group just discussed
The full IRC log of that discussion<gregwhitworth> Topic: [Popup] How should the "popup is top layer" CSS pseudo-class behave, and what should it be called<gregwhitworth> github: https://github.com//issues/470 <gregwhitworth> masonf: we talked about this a few times <gregwhitworth> masonf: there are a few more votes, 6 votes for :top-layer and 2 votes for :overlay <gregwhitworth> masonf: I would like to resolve today and we'll need to take this to CSSWG <gregwhitworth> q? <masonf> Proposed resolution: Rename the "element is in the top layer" pseudo class to `:top-layer`. <masonf> RESOLVED: Rename the "element is in the top layer" pseudo class to `:top-layer`. <JonathanNeal> +1 |
Issue opened on CSSWG to generalize this: w3c/csswg-drafts#7319 |
This CL just does a rename for the :top-layer pseudo class. It does not change behavior, which is/was that this pseudo class only applies to elements using the Popup API [1], and not to all elements that might inhabit the top layer. That will need to wait for a CSSWG resolution. But for now, the [2] resolution means we should use this pseudo class for the Popup API prototype starting now. [1] https://open-ui.org/components/popup.research.explainer [2] openui/open-ui#470 (comment) Bug: 1307772 Change-Id: I81a89132b84346a360d7b580f5f39be9da697bdc
This CL just does a rename for the :top-layer pseudo class. It does not change behavior, which is/was that this pseudo class only applies to elements using the Popup API [1], and not to all elements that might inhabit the top layer. That will need to wait for a CSSWG resolution. But for now, the [2] resolution means we should use this pseudo class for the Popup API prototype starting now. [1] https://open-ui.org/components/popup.research.explainer [2] openui/open-ui#470 (comment) Bug: 1307772 Change-Id: I81a89132b84346a360d7b580f5f39be9da697bdc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3668918 Commit-Queue: Dan Clark <daniec@microsoft.com> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1008430}
This CL just does a rename for the :top-layer pseudo class. It does not change behavior, which is/was that this pseudo class only applies to elements using the Popup API [1], and not to all elements that might inhabit the top layer. That will need to wait for a CSSWG resolution. But for now, the [2] resolution means we should use this pseudo class for the Popup API prototype starting now. [1] https://open-ui.org/components/popup.research.explainer [2] openui/open-ui#470 (comment) Bug: 1307772 Change-Id: I81a89132b84346a360d7b580f5f39be9da697bdc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3668918 Commit-Queue: Dan Clark <daniec@microsoft.com> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1008430}
This CL just does a rename for the :top-layer pseudo class. It does not change behavior, which is/was that this pseudo class only applies to elements using the Popup API [1], and not to all elements that might inhabit the top layer. That will need to wait for a CSSWG resolution. But for now, the [2] resolution means we should use this pseudo class for the Popup API prototype starting now. [1] https://open-ui.org/components/popup.research.explainer [2] openui/open-ui#470 (comment) Bug: 1307772 Change-Id: I81a89132b84346a360d7b580f5f39be9da697bdc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3668918 Commit-Queue: Dan Clark <daniec@microsoft.com> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1008430}
…layer, a=testonly Automatic update from web-platform-tests Rename :popup-open pseudo class to :top-layer This CL just does a rename for the :top-layer pseudo class. It does not change behavior, which is/was that this pseudo class only applies to elements using the Popup API [1], and not to all elements that might inhabit the top layer. That will need to wait for a CSSWG resolution. But for now, the [2] resolution means we should use this pseudo class for the Popup API prototype starting now. [1] https://open-ui.org/components/popup.research.explainer [2] openui/open-ui#470 (comment) Bug: 1307772 Change-Id: I81a89132b84346a360d7b580f5f39be9da697bdc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3668918 Commit-Queue: Dan Clark <daniec@microsoft.com> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1008430} -- wpt-commits: 4f944e32b46acfc971af4ce345fc6b511aea59fe wpt-pr: 34238
…layer, a=testonly Automatic update from web-platform-tests Rename :popup-open pseudo class to :top-layer This CL just does a rename for the :top-layer pseudo class. It does not change behavior, which is/was that this pseudo class only applies to elements using the Popup API [1], and not to all elements that might inhabit the top layer. That will need to wait for a CSSWG resolution. But for now, the [2] resolution means we should use this pseudo class for the Popup API prototype starting now. [1] https://open-ui.org/components/popup.research.explainer [2] openui/open-ui#470 (comment) Bug: 1307772 Change-Id: I81a89132b84346a360d7b580f5f39be9da697bdc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3668918 Commit-Queue: Dan Clark <daniec@microsoft.com> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1008430} -- wpt-commits: 4f944e32b46acfc971af4ce345fc6b511aea59fe wpt-pr: 34238
This CL just does a rename for the :top-layer pseudo class. It does not change behavior, which is/was that this pseudo class only applies to elements using the Popup API [1], and not to all elements that might inhabit the top layer. That will need to wait for a CSSWG resolution. But for now, the [2] resolution means we should use this pseudo class for the Popup API prototype starting now. [1] https://open-ui.org/components/popup.research.explainer [2] openui/open-ui#470 (comment) Bug: 1307772 Change-Id: I81a89132b84346a360d7b580f5f39be9da697bdc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3668918 Commit-Queue: Dan Clark <daniec@microsoft.com> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1008430} NOKEYCHECK=True GitOrigin-RevId: c3b17215facf56ce6dcd2b660766c73b52df903b
This has been discussed in #311, particularly around this comment. Given the new approach for popup, and the associated resolutions not to have a "live"
open
content attribute, we need to revisit this issue. The questions:<dialog>
and fullscreen elements?In my view:
:toplayer
or something similar, rather than:open
which can be confusing for a popup that is "closed" but "visible" in the page.<dialog>
and fullscreen elements.Thoughts appreciated.
The text was updated successfully, but these errors were encountered: