-
Notifications
You must be signed in to change notification settings - Fork 657
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
Comments
FWIW I think
I agree, fwiw. It'd be pretty weird otherwise.
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 |
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 |
I'd rather not add a CSS property until we have some more experience with the |
The CSS Working Group just discussed
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. |
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:@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 todisplay: 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
The text was updated successfully, but these errors were encountered: