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

[flackr]

In general, if something is rendered in the top layer, it probably shouldn't be inert unless explicitly made inert.

I agree. I think UA rule to uninert may work for this case? E.g.

/* TODO: match other things that may be in the top layer. */
dialog:open {
  interactivity: auto; /* Not !important so an author rule on the dialog can override this. */
}

[inert] {
  interactivity: inert;
}

[tabatkins]

There's been more in this thread, but specifically:

interactivity:auto is the initial value, so this won't have an effect (unless you add !important)

No, putting a rule into the cascade, even if it matches the initial value, causes it to defeat inheritance, as we only use the inherited value if nothing wins the cascade.

[lilles]

There's been more in this thread, but specifically:

interactivity:auto is the initial value, so this won't have an effect (unless you add !important)

No, putting a rule into the cascade, even if it matches the initial value, causes it to defeat inheritance, as we only use the inherited value if nothing wins the cascade.

I read that as an attempt to escape "forced inert", which it wouldn't. Is the point of having the UA rule dialog:open { interactivity: auto } that the dialog should not be inert when open/modal in the following case?

<div style="interactivity: inert">
  <dialog id="d"></dialog>
</div>
<script>
  d.showModal();
</script>

[mfreed7]

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

This is a good point, which I've heard a few times. I opened this issue whatwg/html#10811 to discuss this problem more generally. It likely should be "fixed" in WHATWG and not in CSSWG, since the top layer stack is there?

[nt1m]

dialog:modal would be more accurate than dialog:open in the UA rule above fwiw (in terms of matching the current behavior).