-
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] Top layer pseudo class questions #557
Comments
In particular, I should have mentioned, the CSSWG would like us (OpenUI) to discuss the Agenda+ to do that, at least. |
The Open UI Community Group just discussed 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 |
So from the discussion just now, I heard a few things:
In terms of using
Thoughts? Having re-read all of the above discussion, I'm starting to like renaming to either @gregwhitworth I think this can go back on the agenda next week, if possible. |
I feel like A stacking selector like the tree-structural
|
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. |
CSSWG just resolved to add |
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:
::top-layer
element on the<html>
element only, which can be used to select things in the top layer:General thoughts?
The text was updated successfully, but these errors were encountered: