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.

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] Should inertness be exposed as CSS property? #7021

Closed
Loirooriol opened this issue Feb 8, 2022 · 4 comments
Closed

[css-ui] Should inertness be exposed as CSS property? #7021

Loirooriol opened this issue Feb 8, 2022 · 4 comments

Comments

@Loirooriol
Copy link
Contributor

Loirooriol commented Feb 8, 2022

When discussing the inert attribute for HTML, there was some controversy about whether inertness should be propagated to descendants in the flat tree, or to shadow-including descendants.

@rniwa argued that semantic content attributes (like contenteditable, lang, etc.) don't use the flat tree.

@othermaciej argued that inert needs to operate on the flat tree to have its functional effect.

The current situation is that all Blink, WebKit and Gecko implement inertness as part of the computed style, so it propagates in the flat tree, like the CSS cascade. Also, in #6685 we resolved that the effect of inertness can be mostly explained by setting existing CSS properties like pointer-events.

So given the highly presentational nature of inertness, @rniwa proposed that maybe inert should actually be a CSS property:

the correct course of action is to introduce a new CSS property which specifies inertness in CSS since that seems like the most natural mechanism to set inertness anyway. I don’t see any strong reason not to add such a CSS property given most use cases for “inert” seems to involve modifying the style of an element at the same time as inertness.

@cookiecrook argued that it should still be an attribute, but wasn't opposed to also having a reflecting CSS property.

This would be consistent with hidden, which maps to display: none and then works in the flat tree.

Then, should we add this property? Since descendants are not supposed to escape inertness, I guess it would be a non-inherited property that would be propagated to descendants somewhat like text-decoration.

CC @nt1m, @emilio, @chrishtr

@Loirooriol Loirooriol added css-ui-4 Current Work Agenda+ labels Feb 8, 2022
@emilio
Copy link
Collaborator

emilio commented Feb 8, 2022

When discussing the inert attribute for HTML, there was some controversy about whether inertness should be propagated to descendants in the flat tree, or to shadow-including descendants.

@rniwa argued that semantic content attributes (like contenteditable, lang, etc.) don't use the flat tree.

FWIW I think lang in Gecko is implemented as a CSS property and thus would inherit in the flat tree (though interestingly we don't use the flat tree to get the language for selector-matching here, so it's a bit inconsistent).

@othermaciej argued that inert needs to operate on the flat tree to have its functional effect.

I agree, fwiw. It'd be pretty weird otherwise.

Then, show we add this property? Since descendants are not supposed to escape inertness, I guess it would be a non-inherited property that would be propagated to descendants somewhat like text-decoration.

That model seems a bit unfortunate, it would cause us either having to do a tree walk at used value time to query inertness, or be one of these "not-inherited but kinda" properties that introduce special-cases in the CSS engines (like #3344).

Given there's no point in making something non-inert inside something inert (except for modal <dialog> I guess) I'd rather not add a CSS property, tbh.

@Loirooriol
Copy link
Contributor Author

it would cause us either having to do a tree walk at used value time to query inertness, or be one of these "not-inherited but kinda" properties that introduce special-cases in the CSS engines

I was imagining the implementation with two properties: one non-inherited and exposed to authors, the other internal and inherited. Setting the former would set the latter, which would be the one that actually forces pointer-events: none and such.

@annevk
Copy link
Member

annevk commented Feb 16, 2022

lang is discussed in whatwg/html#4906.

I'd rather not add a CSS property until we have some more experience with the inert attribute.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-ui] Should inertness be exposed as CSS property?, and agreed to the following:

  • RESOLVED: Will not add an inertness property for now.
The full IRC log of that discussion <emeyer> Topic: [css-ui] Should inertness be exposed as CSS property?
<emeyer> Github: https://github.com//issues/7021
<JakeA> My slides were all from https://www.youtube.com/watch?v=8FuafvJLDpM
<emeyer> oriol: This is something that appeared in discussions about inertness. The main thing of inertness is it sets events.
<emeyer> …Proposing that inertness shoudl be exposed as a CSS property. It could be like the ‘hidden’ attribute to ‘display: none’.
<emeyer> …Argument in favor is that inert sets certain kinds of styling. This would allow authors to use selectors to make elements inert.
<emeyer> …Atrgument against is that implementations are tracking inertness by way of unexposed inherted properties. If we expose it, then we should probably change this to be non-inherited that propogates by means other than inheritance.
<emeyer> …I don’t have a strong opinion, but would like a resolution one way or the other.
<Rossen_> q?
<emilio> q+
<emeyer> …emilio and annevk expressed oppoition.
<emeyer> emilio: I think this can be added if we want, but given that once an element is inert, it can’t be not-inert, the usefulness of the property seems limited.
<emeyer> …I also don’t like the idea of making a thing propogate outside of inheritance.
<emeyer> s/oppoition/opposition/
<emeyer> Rossen: Does anyone object to waiting until better use cases or louder voices appear?
<emeyer> RESOLVED: Will not add an inertness property for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants