[css-ui-4] Add 'interactivity' property, per #10711

[tabatkins]

No description provided.

[tabatkins]

@flackr @frivoal Mind reviewing? I wanted to match the flat-tree behavior of [inert] in the HTML spec, so I couldn't actually make it an inherited property, but it acts similarly.

[emilio]

Hmm, do you know where is this resolution? In general:

• I don't think that UA CSS works for shadow DOM (does @scope cross shadow boundaries).
• It'd be nice to implement inert-escaping using this property (that's how it works in gecko already fwiw), and I don't see much reason for an author not to do the same?

But I guess I see the point of making inert take precedence... It just probably needs to be style system magic rather than expressed in terms of @scope.

[lilles]

Would it work to introduce pseudo classes for HTML inertness and inert-escaping, similar to how we do directionality and the :dir pseudo class?

/* Applies to [inert] and any [inert] descendants down to, but not including,
   inert-escaping elements. Cannot rely on inheritance since html inertness
   needs to be enforced down the subtree with the !important. */
:inert { interactivity: inert !important }
/* Applies to inert-escaping elements. Inherits into the subtree,
   not !important to allow author CSS to apply inertness. */
:inert-escaping { interactivity: auto }

That means :inert depends on the flat tree, which is also the case for directionality for dir=auto.

[tabatkins]

Rereading #10711, I think that "[inert] must win over CSS" might have been a carryover in my memory from when it was being proposed as a visibility value, to avoid existing code that sets visibility from starting to escape inertness accidentally. It looks like, aside from modal dialogs, we're actually okay with CSS defeating the inert attribute, so long as it's done by a new property that won't trigger problems in legacy code.

But also, you're right, @scope doesn't extend into shadow trees, and inertness needs to (particularly for the forced inertness from modal dialogs). So yeah, we'll need to track a bit coming from the host language.

I'm thinking:

1. The host language can indicate that a given element is "forced inert", which causes interactivity: auto to (behave as? compute to?) inert. This is set on the rest of the page when a modal dialog is active, for example.
2. We add a UA rule for [inert] { interactivity: inert; }, just relying on inheritance.
3. We add a UA rule (either using a normal selector, or a new pseudo-class if the qualities aren't exposed to selectors currently) for dialog, etc { interactivity: auto; }, so they'll escape inertness by default.

[alice]

Sorry I don't have the energy today to make a better thought through comment, but please consider tying inert-escaping behaviour to top layer. At least, don't hastily add some inert-escaping behaviour which will have all the potential downsides we were trying to avoid by not allowing it in the first place.

[lilles]

1. The host language can indicate that a given element is "forced inert", which causes interactivity: auto to (behave as? compute to?) inert. This is set on the rest of the page when a modal dialog is active, for example.

From an implementer point of view, I'd prefer "behave as". Also, I think about it as the interactivity property affects the inertness in the host language, not that the host language affects the computed interactivity in CSS.

2. We add a UA rule for [inert] { interactivity: inert; }, just relying on inheritance.

👍

3. We add a UA rule (either using a normal selector, or a new pseudo-class if the qualities aren't exposed to selectors currently) for dialog, etc { interactivity: auto; }, so they'll escape inertness by default.

I don't think we need this. interactivity:auto is the initial value, so this won't have an effect (unless you add !important). Also, the host language would just make sure dialog and its descendants don't have forced inertness?

[emilio]

That said... Do we really need the "force inert" concept? In Gecko, we currently implement this with an internal pseudo-class that applies to the top of inert subtrees (here).

When a modal dialog is shown, or some element is fullscreen, we apply that pseudo-class to the root element, and another (:-moz-topmost-modal) to the dialog or fullscreen element.

I wonder if the solution is a single property authors can only set to inert (i.e. you can mark subtrees inert with CSS, but not escape inertness, that is handled by the UA)? I think that also addresses @alice's concerns, and doesn't require keeping two flags around.

[lilles]

I think you still need the dialog { interactivity: auto } to make a modal <dialog> inside something like <div inert> work? I think it works everywhere now fwiw.

You mean that the dialog should not be inert in the two cases below? Regardless of whether it's in the top layer or not?

<div inert>
  <dialog></dialog>
</div>
<div style="interactivity:inert">
  <dialog></dialog>
</div>

[emilio]

It should be not-inert when in the top layer, at least, I think.

[flackr]

Being able to escape inertness was a requested ability #10711 (comment) . Is it possible that for dialog or other top layer blocking UI we add a !important inert style to prevent escaping it in the html content but otherwise allow the inert attribute to be escaped?

E.g. something like this

:root:has(dialog:open) {
  interactivity: inert !important;
}
dialog:open {
  interactivity: auto !important;
}

Then the UA rule for the property doesn't need !important.

[alice]

@emilio's suggestion to only allow inert-escaping by the UA would certainly be the most conservative option and would indeed address my concerns.

My main concern is that allowing inert-escaping behaviour essentially based on specificity means that it would be possible to accidentally end up with elements/subtrees which escape inert without realising it, since there is intrinsically no visual impact of making something inert or un-inert (and the un-inerted element may actually be visually inaccessible).

My suggestion to tie un-inerting to the top layer is based on the principle that AT behaviour follows from visual behaviour. Something being in the top layer is a reasonably reliable heuristic that it is visually obscuring other elements, particularly if it has a backdrop.

Working backwards through @scottaohara's very helpful example list of cases for un-inerting from the comment linked above:

(3) Elements outside of a modally-showing dialog which nevertheless need to be showing, in particular using popover elements which exist outside of the dialog. Frankly, this seems like a bug in popover (or even dialog) to me, and could be addressed via Emilio's suggestion of having the UA manage un-inerting. In general, if something is rendered in the top layer, it probably shouldn't be inert unless explicitly made inert.

(2) Live regions for global announcer systems. I'm incredibly sympathetic to this case, but as Scott notes, the ARIA notification proposal is a better fit for the cases not included in (3), and seems to be making good progress. Also, if we make top layer elements automatically un-inert when the page is inerted because of another top layer element, perhaps this could make use of that to promote the announcer element into the top layer and thus out of inert?

(1) UI tours, where (I think) both the popover explaining the relevant part of the UI, and the relevant part of the UI, should be un-inert and un-obscured. I'll admit, this is potentially the most compelling counter-example to my logic. That said, how is the "page is mostly dimmed" behaviour implemented? Could the same mechanism be used to implement "page is mostly inert" using the new property?