- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Apr 2022 17:05:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[selectors] Add :modal-dialog pseudo-class`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: [selectors] Add :modal-dialog pseudo-class<br> <fantasai> github: [selectors] Add :modal-dialog pseudo-class<br> <fantasai> github:https://github.com/w3c/csswg-drafts/issues/6965<br> <fantasai> chrishtr: We discussed whether or not to have pseudo class to have styling of dialogs when open and modal<br> <fantasai> chrishtr: everyone in thread seems to agree<br> <fantasai> chrishtr: Questions raised about putting things in the top layer otherwise<br> <fantasai> chrishtr: think we should put that aside<br> <fantasai> chrishtr: for this specific use case, styling open modal dialogs, pseudo-class makes sense<br> <fantasai> chrishtr: Also question of should there be a generic pseudo-class for top-layer<br> <fantasai> chrishtr: don't think makes sense for a lot of things<br> <fantasai> chrishtr: first, very generic<br> <fantasai> chrishtr: second, ???<br> <fantasai> chrishtr: third, not necessarily even top<br> <fantasai> chrishtr: so :modal-dialog or :modal seems best<br> <fantasai> chrishtr: This would be similar to existing :fullscreen pseudo-class<br> <fantasai> chrishtr: If we have popups or tooltips, we can add pseudo-classes for those as well<br> <fantasai> astearns: Tantek in IRC wanted to know if this was discussed in the OpenUI group<br> <fantasai> masonf: Yes, we've discussed this a lot, and also talking about a similar pseudo-class for pop-ups<br> <fantasai> masonf: It seemed to me at the beginning to have a single pseudo-class for the top layer, though I see the points raise dhere<br> <fantasai> masonf: and discussed in OpenUI<br> <emilio> q+<br> <tantek> I don't have a strong/informed opinion either way, just making sure that sync-up had occured and there was some degree of mutual consensus<br> <fantasai> masonf: Concern that as we add more and more things to top layer, will have more and more such pseudo classes<br> <fantasai> masonf: but maybe that's OK<br> <astearns> ack emilio<br> <ntim> q+<br> <fantasai> emilio: I wanted to say that for popups, may even make sense to just use :modal as well, if we're not going with :modal-dialog<br> <fantasai> chrishtr: That was one of the reasons suggested to use :modal rather than :modal-dialog<br> <masonf> q+<br> <fantasai> chrishtr: for things that are truly :modal, can add to its semantics<br> <astearns> ack ntim<br> <fantasai> ntim: I think it's easy to implement, but I don't see the appeal of adding :modal pseudo-class because you can technically use the [open] attribute to target the state<br> <fantasai> ntim: It's very rare for a developer to trigger the same dialog in both modal and non-modal state<br> <argyle> q+<br> <fantasai> TabAtkins: Part of issue was needed to expose to UA style sheet, and if exposing to UA stylesheet might as well expose to authors as well<br> <fantasai> astearns: Why not use [open]?<br> <tantek> +1 TabAtkins to expose "modal" to the UA stylesheet<br> <fantasai> TabAtkins: Only tells whether opened or not, not whether opend modally<br> <fantasai> TabAtkins: and we need to add UA stylesheet rules specific to modal case<br> <argyle> https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/resources/html.css;l=1400;bpv=1<br> <fantasai> ntim: ...<br> <astearns> ack masonf<br> <fantasai> masonf: 2 things, to the last point we did discuss also the open attribute for popup and decided it was a bad pattern, so moving to pseudoclasses for all of these<br> <fantasai> masonf: also because we're going down the road to make specific pseudo-classes per type of thing that goes into top layer, would vote against :modal<br> <fantasai> masonf: :popup:modal vs :popup:not(:modal) is weird<br> <fantasai> masonf: I think we should give a more specific name to dialog<br> <astearns> ack argyle<br> <fantasai> argyle: I like the idea of a single name<br> <fantasai> argyle: why not :top-layer<br> <fantasai> argyle: sounds like what it is<br> <tantek> I'd tend to agree with masonf's reasoning, and there's the risk that authors using a general :modal for just dialogs would errantly apply to future "modal" things and perhaps constrain our future compat<br> <fantasai> argyle: Top Layer holds a pseudo version of these, but dom node is somewhere in the tree, and pseudo-class is on the new magical one, so I think that's an interesting distinction here<br> <fantasai> argyle: if we do expose this pseudo-class, what *can't* be styled on it? z-index tricks? top layer's job is to manage order<br> <fantasai> argyle: I think we're just talking about the name now<br> <fantasai> argyle: but what can't be put there is the question I'd like to ask<br> <fantasai> astearns: Since we're not close to agreeing on the name yet, let's push of question fo what will apply to the pseudo for this<br> <fantasai> TabAtkins: That does have a simple answer, actually. Pseudo-classes don't have restrictions<br> <masonf> q+<br> <fantasai> TabAtkins: what modal dialogs might pay attention to is a different question<br> <astearns> ack masonf<br> <TabAtkins> q+<br> <fantasai> masonf: That said, what Tab said is technically true, but we need to resolve first on whether the pseudo-class applies only to dialogs or can also apply to other things<br> <bkardell_> q+<br> <fantasai> astearns: I thought last comment, you thought it wouldn't apply to anything else, that wouldn't be other things in the future<br> <fantasai> masonf: There are 2 approaches, one is to make a generic pseudo that would apply to things, e.g. popup, that goes in top layer<br> <fantasai> masonf: One, to make a general pseudo<br> <fantasai> masonf: Two, make a specific pseudo for each type of thing<br> <fantasai> masonf: talked about fullscreen, then modal dialogs, then popups<br> <fantasai> masonf: Thread has been going to different names to different things, but need to resolve that<br> <astearns> ack TabAtkins<br> <tantek> +1 specific names for each thing<br> <fantasai> TabAtkins: Just want to agree with Mason, thread leaned towards separate things for each thing in the future, because not sure about extensibility quesiton, and going generic early can be a problem because can write selectors that are too generic<br> <fantasai> TabAtkins: so I think individual pseudo-casses is a better approach<br> <fantasai> TabAtkins: ...<br> <chrishtr> +1 to individual cases<br> <fantasai> TabAtkins: For this thing, better to design specifically for modal dialog case<br> <astearns> ack bkardell_<br> <TabAtkins> s/.../for example, a future thing wanting to target its modal-ness might want a functional pseudo-class/<br> <fantasai> bkardell_: So, I've been in a number of conversations about this, and i quickly scanned through the issue because some of the convsersation around do we actually need a pseudo-class hit on for me<br> <fantasai> bkardell_: I don't think we've discussed if can use media query for this?<br> <fantasai> bkardell_: could have media query for top layer, when top layer is shown and relevant, then can just use regular selectors<br> <fantasai> bkardell_: Any reason that's a bad idea?<br> <emilio> q+<br> <TabAtkins> fantasai: I think you want to know *which* element is in the top layer<br> <TabAtkins> fantasai: Say you have five videos on teh page, and one is full screen, you wanna know which one it is, but MQ can just tell you that *something* is full screen, nto which one<br> <emilio> q-<br> <TabAtkins> fantasai: Same to dialogs<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: My q was for... "modal" isn't abut being in the top layer, it's about being modal and not accessing other things<br> <emilio> q+<br> <TabAtkins> fantasai: I'd prefer we not confuse this with "being in the top layer" concept<br> <masonf> q+<br> <TabAtkins> astearns: So that sounds like a vote for a specific :modal-dialog, rather than :modal or :top-layer<br> <astearns> ack emilio<br> <TabAtkins> fantasai: Dunno about :modal but no to :top-layer<br> <ydaniv> +1 potentially there could be more than one dialog (:<br> <fantasai> emilio: related to what fantasai said, multiple modal dialogs can be open at the same time, and only one is interactable at a given time<br> <fantasai> emilio: but UA style sheet is styling all of them<br> <masonf> q-<br> <fantasai> emilio: not just the last dialog opened in this way<br> <bkardell_> 'active-modal'<br> <fantasai> emilio: so already a bit of distinction, that all dialogs open with openModal, they are in top layer but not necessarily ???<br> <fantasai> TabAtkins: I don't think she's saying that opening nested modals that it wouldn't apply to stuff under the stack<br> <fantasai> astearns: I think what I'm hearing is a growing consensus for a pseudo that targets the dialog specifically not its top-layer-ness<br> <TabAtkins> Basically it's still opened "as modal", even if tehcnically we're in a mode allowing interaction with a nested thing now<br> <masonf> q+<br> <fantasai> astearns: and for something that notes that it's a modal dialog, not some other modal or top-layer thing<br> <astearns> ack masonf<br> <fantasai> astearns: sounds like we want to choose :modal-dialog?<br> <fantasai> masonf: I think pseudo should only apply to dialog, and only to the top layer<br> <fantasai> masonf: So if three opened into top layer, only top one is :modal<br> <lea> dialog:modal-dialog is a bit clumsy<br> <bkardell_> the top top top layer one :)<br> <fantasai> s/:modal/modal in the sense that can interact with it, but all match the pseudo class/<br> <TabAtkins> lea, don't do that then. `:modal-dialog` is sufficient<br> <fantasai> fantasai: I don't think "modal" means the top active one, it means mutually exclusive, top one happens to be active<br> <fantasai> plinss: We have other pseudo-classes :active<br> <fantasai> plinss: Could make a combo of states to get a full description<br> <fantasai> plinss: Also, pseudo-classes are supposed to represent state<br> <fantasai> plinss: I'm not thrilled with :modal-dialog if can go in and out of being a dialog<br> <fantasai> plinss: If it can't change the state of being a dialog, then don't see why pseudo-class<br> <fantasai> emilio: Discussing whether :modal or :modal-dialog<br> <lea> +1 to plinss<br> <bkardell_> :modal and :modal:active is what plinss is suggesting?<br> <fantasai> +1 to plinss<br> <fantasai> TabAtkins: Argument against that is we're not certain that other things that can be modal would match this pseudo-class<br> <fantasai> TabAtkins: and concerned that people would write :modal without specifying dialog:modal, and in future might break pages if we extend to other things<br> <fantasai> plinss: Solve it with education<br> <fantasai> TabAtkins: solve right now with a restrictive name<br> <masonf> +1 to tabatkins. Clear naming is the best documentation.<br> <fantasai> astearns: If in the future, have multiple things, where can have multiple thing, we can add :modal<br> <fantasai> plinss: I would hate to get to a point where we have :modal-foo :modal-bar :modal-baz, if we have concept of modalness, let's have that be the pseudo-class<br> <bkardell_> +1 to what plinss just said<br> <lea> another +1 to what plinss just said<br> <emilio> q+<br> <fantasai> plinss: if need to distinguish, use other selectors to make more specific<br> <masonf> q+<br> <fantasai> astearns: OpenUI didn't want to do that<br> <fantasai> plinss: They might be utilitarian about that. If the thing you care about is being in top layer, have a pseudo-class for that. If care about being modal, have a pseudo-class for that. Don't conflate things, not have one pseuod-class for everything. Let's have one pseudo-class for each thing.<br> <astearns> ack emilio<br> <fantasai> plinss: not one pseudo class for being modal and top layer and dialog all at once<br> <TabAtkins> I've already made my argument against this exact thing and don't think it would b euseful to repeat myself again<br> <fantasai> emilio: All top-layer dialogs are modal, so for dialogs they are interchangeable, but for popups it would not be<br> <fantasai> emilio: I don't know, I just wanted to say that we can choose a more specific name, and if need generalize can always alias pseudo-classes<br> <fantasai> emilio: We've done this in the past with prefixes and stuff<br> <fantasai> emilio: parse :modal-dialog same as :modal in the future<br> <fantasai> emilio: But again, I don't care too much about the name. I would be fine with :modal<br> <astearns> ack masonf<br> <fantasai> masonf: +1 to what emilio said<br> <TabAtkins> (I'm just fine with a profusion of :modal-* things in the future *if we end up with that*; it's really not an issue whether authors spell their selectors `dialog:modal` or `:modal-dialog`.)<br> <fantasai> masonf: populs can be shown, or not shown, or in the top layer<br> <fantasai> masonf: dialogs are modal and top layer at the same time<br> <fantasai> masonf: so seems wer'e veering towards more generic pseudo-class<br> <TabAtkins> (But *if we end up with that*, yes, we can just add :modal at that point.)<br> <fantasai> masonf: if we're choosing one of those two, let's go with top-layer since that would apply to pop-ups and then we can reuse it<br> <fantasai> plinss: guarantee that dialog not modal?<br> <fantasai> TabAtkins: modalness and toplayerness are tied together for dialog, but potentially not for other things<br> <fantasai> plinss: Maybe form of dialog that can be in the top layer but not modal, right?<br> <argyle> +1 :top-layer<br> <fantasai> masonf: then pseudo class should be :top-layer<br> <lea> +1 :top-layer and keeping concepts decoupled<br> <fantasai> plinss: but that's my argument against conflating these things. Just because you expect to be :modal and :top-layer at the same time, don't have pseudo that means both at the same time<br> <chrishtr> q+<br> <fantasai> masonf: If want to go that route with :modal, then let's have :modal and :top-layer, so both would apply to dialog and can re-use those concepts for other things like popups<br> <fantasai> plinss: That was precisely my point<br> <fantasai> plinss: different pseudo-class for different states<br> <TabAtkins> My big point here is that any generic design is making some big assumptions about what will be useful in the future, and what sort of things we'll design in the future. There are zero guarantees here!<br> <bkardell_> can we just take that back to openui, I feel like this is reasonable and people will be good with it<br> <fantasai> masonf: I'm OK with either one<br> <astearns> ack chrishtr<br> <emilio> q+<br> <fantasai> chrishtr: I think you made a good point that pseudo-classes should have a single meaning, and should be clear<br> <TabAtkins> Let's backfill as needed in the future and just solve the narrow cases now, in a way that doesn't *block* good backfill names.<br> <fantasai> chrishtr: I think ?? meets that bar, don't think :top-layer is immediately needed atm, so I suggest we attempt to resolve on :modal for now<br> <astearns> ack emilio<br> <fantasai> emilio: I agree on trying to go for :modal for now, because that's what we need for UA style sheet<br> <fantasai> emilio: also now I think about it, nothing preventing you from calling fullscreen on a dialog element<br> <fantasai> emilio: so that would create a dialog that's top layer, but not modal<br> <chrishtr> good point about fullscreen<br> <fantasai> emilio: ...<br> <chrishtr> :modal is good I think<br> <masonf> That would match :fullscreen<br> <chrishtr> Modal is a very clear UI concept<br> <fantasai> emilio: Seems we need a selector for modal dialogs, at least for UA stylesheet. If we want to expose for authors, that's great.<br> <chrishtr> same with fullscreen - it's also very clear as a UI concept (and state)<br> <fantasai> emilio: if we want :top-layer in future, that's fine, but different issue<br> <fantasai> emilio: so think I'm with chris here<br> <argyle> i dont think a dialog can go fullscreen<br> <masonf> Modal is not super clear to developers. On popup, we're constantly discussing why there isn't a modal popup.<br> <TabAtkins> I just don't like genericizing from 1 example.<br> <fantasai> +1 to :modal given argument lately<br> <masonf> argyle you're right, it's prohibited by spec.<br> <fantasai> astearns: So back to just :modal, but some people on IRC that were really happy with :top-layer version, anyone want to pseak against :modal<br> <fantasai> TabAtkins: I'm still against :modal by itself, don't want to block future use of :modal, by choosing overly generic name now<br> <tantek> +1 TabAtkins let's not genericize from a single example. premature abstraction and all that.<br> <argyle> +1 to :top-layer, not sure about :modal<br> <fantasai> masonf: +1 to TabAtkins<br> <fantasai> masonf: Already confusion with popup<br> <fantasai> plinss: I don't think an overly generic name is overly generic if we constrain its meaning to what it really means<br> <fantasai> plinss: if we have :modal, it describes modalness, period.<br> <fantasai> plinss: It is generic, and maybe we only have one use for it now, but we know when we have a future use of it<br> <chrishtr> +1 to plinss<br> <masonf> https://github.com/openui/open-ui/issues/325<br> <fantasai> TabAtkins: People will use it for that one thing now, and it will be a problem now<br> <vmpstr> should it have been :hover-a?<br> <masonf> q+<br> <fantasai> TabAtkins: Tantek points out :hover only applied to links, and when started applying to everything was a problem<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <tantek> I guarantee web authors will be lazy and not bother to scope :modal to only dialogs to start with.<br> <chrishtr> Good point fantasai<br> <TabAtkins> yup to tantek<br> <tantek> I also agree with fantasai's distinction of the two cases<br> <fantasai> fantasai: This is different from :hover, because i nthat case we had :hover restricted to one element even though hovering could apply to any element, and when we expanded to allow all elements it was a problem<br> <tantek> s/i nthat/in that<br> <fantasai> fantasai: but here we're proposing :modal to apply to *all things* that are modal, which happens to currently only be one thing<br> <fantasai> fantsasai: It will never apply to other things that exist now, because none of them are modal<br> <fantasai> fantasai: it might apply to new things in the future that are modal, that's it<br> <fantasai> fantasai: so it's a different situation<br> <TabAtkins> Note that "being in the top layer" is *not* what we need for the UA stylesheet, so it wouldn't solve the original problem.<br> <emilio> argyle: you're right: https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen has a "not dialog" check<br> <fantasai> masonf: It sounds like we're goint towards a generic concept, dialogs have both modalness and toplayerness<br> <fantasai> masonf: posted concept about modalness being a spectrum, but toplayerness is binary<br> <TabAtkins> Oh weird that fullscreen specifically avoids that<br> <bkardell_> Just wanted to note before everyone leaves that Igalia's Web Engine's Hackfest is happening again in June in spain, a kind of hybrid, but as always we would love any or all csswg members to come, good things happen there <3 https://webengineshackfest.org/2022/ feel free to reach out to me, eric or rego if you want more information or have questions<br> <fantasai> masonf: if we need one, we should use top layer<br> <fantasai> astearns: Way out of time, take it back to the issue, but I think this was productive discussion.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6965#issuecomment-1111250965 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 April 2022 17:05:19 UTC