[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]

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.

[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.