- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 May 2022 16:57:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[selectors] Should :active apply to dialogs?`, and agreed to the following: * `RESOLVED: issue of topmost modal dialog to be addressed with a pseudo-class (name TBD)` <details><summary>The full IRC log of that discussion</summary> <dbaron> Topic: [selectors] Should :active apply to dialogs?<br> <dbaron> github: https://github.com/w3c/csswg-drafts/issues/7258<br> <dbaron> plinss: The sense is that there can be multiple modal dialogs and only one is active. Should have a pseudo class for it. I propose we re-use the :active pseudo class, though what pseudo used is not that important.<br> <emilio> q+<br> <ntim> q+<br> <dbaron> plinss: There was a lot of pushback against using :active. I accept it could be problematic... many people seem to think :active means the mouse is down, but I think it means the thing is active.<br> <Rossen_> ack emilio<br> <dbaron> emilio: I was going to echo that... :active applies to all elements when you press the mouse, regardless of whether they're activatible. So I think it would be very confusing to use it for this. Especially because it would trigger when you click something in a dialog, because :active applies to the whole chain of things.<br> <dbaron> emilio: I don't know that the pseudo is that useful -- can't think of cases where you want different styling for the topmost modal dialog from other modal dialogs.<br> <dbaron> Rossen_: Is the point you're making that an active modal dialog must always be the topmost one, and ... ?<br> <dbaron> emilio: I think reusing :active would be a mistake because it already applies to <dialog>, and that I don't think there's a lot of use cases for styling the active (i.e., topmost) dialog versus styling a modal dialog that is not the topmost one.<br> <dbaron> emilio: We need to do that internally for inertness, but that's just to control inertness of the topmost thing.<br> <dbaron> plinss: If you have nested dialogs, I can see wanting to differentiate them visually. They may not necessarily be on top of each other or obviously obscuring each other. I think there's a valid use case for it.<br> <dbaron> emilio: Fair. I guess I think it's something the backdrop usually takes care of.<br> <dbaron> plinss: Depends on what effect backdrop has and whether it's obvious.<br> <Rossen_> ack ntim<br> <dbaron> ntim: I'm also against using :active for this. If you're really targeting the dialog ??? ... that would make it incompatible.<br> <dbaron> ntim: :active has a historical meaning, so I'm against doing that.<br> <dbaron> ntim: I also don't see a lot of use cases. But my main pushback was using :active.<br> <dbaron> ntim: Personally regarding use cases, since modal dialogs are triggered using javascript, you can control which class you put on the topmost one. I don't see a real gain from adding pseudo-class.<br> <emilio> q+<br> <dbaron> plinss: You could make that argument about almost every pseudo-class. Let me push back on :active meaning the mouse is down -- I don't think that was original intent. I think it was a mistake -- not sure if it's one we can fix.<br> <dbaron> ntim: Let's say you have a button inside a dialog, and you're pressing that button. Unexpected that :active would apply, given that :active propagates to parent elements.<br> <dbaron> plinss: It would already be active if the button is clickable<br> <dbaron> emilio: not if the dialog isn't modal<br> <Rossen_> q<br> <dbaron> emilio: If I understand correctly, this would make a pseudo for the topmost modal dialog. Would be confusing for that pseudo to apply to non-modal dialogs.<br> <Rossen_> +1 to emilio and :active interop being bad<br> <dbaron> emilio: Put on queue to say that :active interop is pretty bad. This would make it a lot more confuesing.<br> <Rossen_> ack emilio<br> <Rossen_> ack fantasai<br> <chrishtr> q+<br> <dbaron> fantasai: I agree we can't use :active given how it's been reinterpreted by implemented. Was never intended to be "while I'm clicking on this element".<br> <dbaron> fantasai: I can see there might be use cases for having a pseudo-element for the topmost modal. Wish we could use the word active for it, maybe :active-modal or similar.<br> <dbaron> Rossen: I'd like to break the solution into validating the use case and coming up with a solution, and then the bikeshedding.<br> <dbaron> Rossen: Would like to validate the use case first.<br> <dbaron> chrishtr: To the point about developers don't need it because they control the dialogs... it's still convenient because it's very simple to just have to style the frontmost dialog and not have to use script to polyfill the same thing.<br> <dbaron> Rossen_: I agree with that too.<br> <Rossen_> q?<br> <dbaron> Rossen_: sounds like there's more validation to the use case... name of the pseudo TBD.<br> <dbaron> Rossen_: Would prefer to take bikeshedding back to the github issue.<br> <dbaron> ntim: If you have a UI that does stacking multiple dialogs... it's not a great UI. This sort of encourages it in some way. I guess the role of CSS isn't how to say how to build UIs.<br> <tantek> I would like to get input from the OpenUI folks on this<br> <dbaron> plinss: I agree stacking modal dialogs is a bad pattern... though maybe modal dialogs are a bad pattern to begin with. If we're going to do them we should do them well.<br> <tantek> I didn't see any in https://github.com/w3c/csswg-drafts/issues/7258<br> <tantek> q+<br> <dbaron> plinss: ... goes against my earlier advice about allowing authors to do bad things.<br> <dbaron> tantek: I'm looking at issue and leaning towards plinss opinion as well. But haven't considered motivating use cases.<br> <dbaron> tantek: I think OpenUI folks should comment... may have more context of uses cases that would need this pseudo class... or they've considered it and decided they don't need it.<br> <dbaron> Rossen_: I think the decision of styling the active modal dialog througha pseudo-class is seemingly obvious decision even if we invalidate the use case later.<br> <dbaron> Rossen_: I'd like to record a decision here....<br> <fantasai> s/do bad things/do bad things, but arguably modal dialogs in general are a bad idea. If we're going to do them, though, let's do them well./<br> <dbaron> ntim: Looking at top layer generall, maybe use case is targeting topmost thing in top layer rather than active modal dialog. Look at it from different perspectives as well.<br> <smfr> plinss: the second one<br> <dbaron> ntim: How does this fit with other things that use the top layer -- full screen api, popup api.<br> <dbaron> ntim: How does this pseudo fit with this stuff... and should it be more generic to these things?<br> <dbaron> ntim: so maybe openUI input would be good.<br> <dbaron> plinss: Happy to get openUIs input, but would like to take a resolution to have a pseudo-class.<br> <chrishtr> +1 to resolving to add a pseudoclass now. :modal-active ?<br> <dbaron> Rossen: Proposed resolution that issue of topmost modal dialog to be addressed with a pseudo-class (name TBD).<br> <dbaron> RESOLVED: issue of topmost modal dialog to be addressed with a pseudo-class (name TBD)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7258#issuecomment-1130259581 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 May 2022 16:57:47 UTC