Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

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

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4c51c53
[css-ui-4] Add 'interactivity' property, per #10711
tabatkins Nov 11, 2024
ec8cf37
[css-ui-4] Sigh, inheritance *does* work on the flat tree, I'm dumb.
tabatkins Nov 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
84 changes: 83 additions & 1 deletion css-ui-4/Overview.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,6 +62,7 @@ Ignore Can I Use URL Failure: https://drafts.csswg.org/css-ui-4/
Ignore Can I Use URL Failure: http://drafts.csswg.org/css-ui-4/
Ignore Can I Use URL Failure: https://www.w3.org/TR/css-ui-4/
Ignore Can I Use URL Failure: http://www.w3.org/TR/css-ui-4/
Indent: 2
</pre>

<pre class=link-defaults>
Expand Down Expand Up @@ -103,7 +104,8 @@ spec:css-backgrounds-3; type:property; text:border-left-color
</pre>
<pre class=anchors>
urlPrefix: https://html.spec.whatwg.org/multipage/; spec:HTML
text:password; type:attr-value; for:input/type; url: input.html#attr-input-type-password-keyword
type:attr-value; text:password; for:input/type; url: input.html#attr-input-type-password-keyword
type:element-attr; text:inert; for:html-global; url: interaction.html#the-inert-attribute
</pre>

<style>
Expand Down Expand Up @@ -1972,6 +1974,86 @@ Exclusion from Hit-testing: the 'pointer-events' property</h3>
with more possible values.
The effect of such values outside of SVG is currently not defined.

<h3 id="inertness">
Preventing All Interaction: the 'interactivity' property</h3>

<pre class=propdef>
Name: interactivity
Value: auto | inert
Initial: auto
Applies to: all elements
Inherited: yes
Percentages: N/A
Computed Value: as specified
Animation type: discrete
</pre>

The 'interactivity' property specifies whether an element and its [=flat tree=] descendants
(including [=text runs=])
are [=inert=] or not.

<dl dfn-type=value dfn-for=interactivity>
: <dfn>auto</dfn>
::
Unless otherwise specified by the host language,
the element is not [=inert=].

: <dfn>inert</dfn>
:: The element is [=inert=].
</dl>

<div algorithm>
When an [=element=] or [=text run=] is <dfn export>inert</dfn>:

* Hit-testing must act as if 'pointer-event' was ''pointer-events/none'',
regardless of its actual value.
* Text selection must act as if 'user-select' was ''user-select/none'',
regardless of its actual value.
* If the [=element=] or [=text run=] is editable,
it must behave as if it was non-editable.
* The [=element=] or [=text run=] should be ignored
for the purposes of find-in-page and similar searching actions.

User agents may allow the user
to override the restrictions on find-in-page and text selection.
</div>

Note: [=Inert=] nodes generally cannot be focused,
and user agents do not expose the inert nodes
to accessibility APIs or assistive technologies.
An inert subtree should not contain any content or controls
which are critical to understanding or using aspects of the page
which are not in the inert state.
Content in an inert subtree will not be perceivable by all users, or interactive.
Authors should not specify elements as inert
unless the content they represent are also visually obscured in some way.
In most cases,
authors should not specify the inert attribute on individual form controls.
In these instances, the <{input/disabled}> attribute is probably more appropriate.

<div class=issue>
The HTML <{html-global/inert}> attribute is meant to be stronger
than the 'interactivity' property,
per CSSWG resolution.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  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.

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

👍

  1. 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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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;
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

This should be achieved by the following user-agent CSS:

<pre highlight=css>
@scope ([inert]) to (X) {
* {
interactivity: inert !important;
}
}
X {
interactivity: auto;
}
</pre>

Where the <css>X</css> represents a theoretical selector
matching any elements that "escape" inertness by default,
such as modal dialogs.
</div>



<h2 id="styling-widgets" oldids="form-styling, control-styling">
Styling Widgets</h2>
Expand Down