-
Notifications
You must be signed in to change notification settings - Fork 210
[Popup] How should the "popup is top layer" CSS pseudo class behave, and what should it be called #470
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
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 [[email protected]] 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_ [[email protected]] 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 [[email protected]] 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 |
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 |
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 |
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 ClarkAuto-Submit: Mason Freed Reviewed-by: Dan Clark 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 ClarkAuto-Submit: Mason Freed Reviewed-by: Dan Clark 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 ClarkAuto-Submit: Mason Freed Reviewed-by: Dan Clark 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 ClarkAuto-Submit: Mason Freed Reviewed-by: Dan Clark 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 ClarkAuto-Submit: Mason Freed Reviewed-by: Dan Clark Cr-Commit-Position: refs/heads/main@{#1008430} -- wpt-commits: 4f944e32b46acfc971af4ce345fc6b511aea59fe wpt-pr: 34238
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: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.and fullscreen elements.
Thoughts appreciated.
The text was updated successfully, but these errors were encountered: