[selectors] Should :active apply to dialogs?

[plinss]

Now that we have :modal, we have the situation where there can be multiple open modal dialogs, but only one of them can be considered active at a time. Should we distinguish the active modal dialog with the :active selector?

e.g. The currently active modal dialog can be selected via :modal:active.

[bramus]

Would love to see this, but conflicts with the current use/definition of :active, which also works on non-links

The :active pseudo-class applies while an element is being activated by the user. For example, between the times the user presses the mouse button and releases it.

[Loirooriol]

Example of what bramus said: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/10287

[tabatkins]

Yeah :active already has a defined meaning on all elements, we can't reuse it for something different now.

[plinss]

Two points:

1. regardless of what it's called, we need a pseudo-class to distinguish the currently active dialog, since multiple dialogs can be open and modal at the same time and there's no other way to distinguish the active one.

2. I don't believe the :active pseudo-class is defined in such a way as to prohibit it's use here. It is defined to mean 'being activated by the user' not 'has the mouse down on it'. The 'mouse down' trigger of activation state was an example only meant to have meaning on buttons (or other clickable elements, and for elements that don't have a clickable behavior, maybe :active on mouse down should only apply when there's a 'click' or 'mousedown' event handler). The fact that browsers get this wrong can be considered a bug, and I don't see why we can't tighten up the definition of 'being active' on specific elements, especially those that have a well defined 'active' state, like modal dialogs (tho that would belong in HTML). In fact, in @Loirooriol's example on iOS the dialog only has the active state when text is selected inside the dialog.

[tabatkins]

Changing the definition of :active when it's been widely implemented as it currently is for many years doesn't seem wise or likely to be web compatible.

The use-case we had for the pseudo-class in the first place was distinguishing modal from non-modal dialogs so we could style them differently in the UA stylesheet (and we figured authors might have some use for it). Do you have a use-case for styling the active modal differently from modals that are currently "further down" the modal stack?

[plinss]

I'm not talking about redefining :active for everything here*, but only defining it to have a different behavior for a single, new, element. I don't see that breaking existing content (unless someone really did something when a dialog is being clicked on).

The use case is for making the active dialog visually distinctive when the author is using multiple nested modal dialogs, like putting a highlight around it (or dimming the non-active ones). (I also don't see a use case for styling a dialog that's being clicked on, content within the dialog, sure, but not the dialog itself, unless it's being dragged, but that's something else and shouldn't be considered active anyway.)

(*) I did mention that it should only apply to non-clickable elements when there's an event handler present, but that's an entirely separate issue (and not so much a redefinition as an argument to respect the original specified definition), and I accept has web compat concerns.

[tabatkins]

Even if there is zero code in the wild today styling a dialog with :active, I think it would be a really bad idea to have it mean something different on dialogs when it has a consistent meaning (actively being clicked on) for every other element.

Ignoring the syntax question, tho, what's your use-case for targetting the current active modal with selectors?

[plinss]

The use case is for making the active dialog visually distinctive when the author is using multiple nested modal dialogs, like putting a highlight around it (or dimming the non-active ones). (I also don't see a use case for styling a dialog that's being clicked on, content within the dialog, sure, but not the dialog itself, unless it's being dragged, but that's something else and shouldn't be considered active anyway.)

[plinss]

I'll also state the :active pseudo was not meant to mean 'actively being clicked on' it meant 'active', it's just that the things that get active so far have done so by being clicked on. If we meant 'being clicked on' we should have called it :click or :press. The case of the mouse being down was an example not a hard definition.

[nt1m]

Re-using :active would be confusing, given it has a historical meaning for web developers. Fwiw, Firefox has an internal :-moz-topmost-modal-dialog pseudo-class.

Though, I don't find it particularly useful to expose this to web developers, given they control which dialog(s) they show.

[LeaVerou]

I agree with @tabatkins that re-using :active with an entirely different meaning would be a terrible idea. While I understand that :active was originally defined to be a little vague, the reality is that today it means "pointer is pressed over the element".

I would however support having a pseudo-class for what @plinss is proposing. I don't have any good ideas for what to call it (:active would have been an excellent name if it didn't have baggage).

[chrishtr]

Maybe :modal-active as a name?

[css-meeting-bot]

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)

The full IRC log of that discussion

<dbaron> Topic: [selectors] Should :active apply to dialogs?
<dbaron> github: https://github.com//issues/7258
<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.
<emilio> q+
<ntim> q+
<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.
<Rossen_> ack emilio
<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.
<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.
<dbaron> Rossen_: Is the point you're making that an active modal dialog must always be the topmost one, and ... ?
<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.
<dbaron> emilio: We need to do that internally for inertness, but that's just to control inertness of the topmost thing.
<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.
<dbaron> emilio: Fair. I guess I think it's something the backdrop usually takes care of.
<dbaron> plinss: Depends on what effect backdrop has and whether it's obvious.
<Rossen_> ack ntim
<dbaron> ntim: I'm also against using :active for this. If you're really targeting the dialog ??? ... that would make it incompatible.
<dbaron> ntim: :active has a historical meaning, so I'm against doing that.
<dbaron> ntim: I also don't see a lot of use cases. But my main pushback was using :active.
<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.
<emilio> q+
<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.
<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.
<dbaron> plinss: It would already be active if the button is clickable
<dbaron> emilio: not if the dialog isn't modal
<Rossen_> q
<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.
<Rossen_> +1 to emilio and :active interop being bad
<dbaron> emilio: Put on queue to say that :active interop is pretty bad. This would make it a lot more confuesing.
<Rossen_> ack emilio
<Rossen_> ack fantasai
<chrishtr> q+
<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".
<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.
<dbaron> Rossen: I'd like to break the solution into validating the use case and coming up with a solution, and then the bikeshedding.
<dbaron> Rossen: Would like to validate the use case first.
<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.
<dbaron> Rossen_: I agree with that too.
<Rossen_> q?
<dbaron> Rossen_: sounds like there's more validation to the use case... name of the pseudo TBD.
<dbaron> Rossen_: Would prefer to take bikeshedding back to the github issue.
<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.
<tantek> I would like to get input from the OpenUI folks on this
<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.
<tantek> I didn't see any in https://github.com//issues/7258
<tantek> q+
<dbaron> plinss: ... goes against my earlier advice about allowing authors to do bad things.
<dbaron> tantek: I'm looking at issue and leaning towards plinss opinion as well. But haven't considered motivating use cases.
<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.
<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.
<dbaron> Rossen_: I'd like to record a decision here....
<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./
<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.
<smfr> plinss: the second one
<dbaron> ntim: How does this fit with other things that use the top layer -- full screen api, popup api.
<dbaron> ntim: How does this pseudo fit with this stuff... and should it be more generic to these things?
<dbaron> ntim: so maybe openUI input would be good.
<dbaron> plinss: Happy to get openUIs input, but would like to take a resolution to have a pseudo-class.
<chrishtr> +1 to resolving to add a pseudoclass now. :modal-active ?
<dbaron> Rossen: Proposed resolution that issue of topmost modal dialog to be addressed with a pseudo-class (name TBD).
<dbaron> RESOLVED: issue of topmost modal dialog to be addressed with a pseudo-class (name TBD)