Intent to Implement: inert attribute

[Alice Boxhall]

Contact email

abox...@chromium.org

Spec

https://github.com/WICG/inert#spec

Summary

The `inert` attribute would allow web authors to mark parts of the DOM tree as inert:

When a node is inert, then the user agent must act as if the node was absent for the purposes of targeting user interaction events, may ignore the node for the purposes of text search user interfaces (commonly known as "find in page"), and may prevent the user from selecting text in that node.

Furthermore, a node which is inert should also be hidden from assistive technology.

Motivation

Developers find themselves in situations where they'd like to be able to mark a part of the page "un-tabbable". Rob Dodson lays out one such example in "Building better accessibility primitives":

One problem: to [achieve a performance optimisation for animation] we must leave the drawer in the DOM at all times. Meaning its focusable children are just sitting there offscreen, and as the user is tabbing through the page eventually their focus will just disappear into the drawer and they won't know where it went. 

See the explainer for more use cases.

 

`inert` would also allow more straightforward polyfilling of both <dialog> and any more primitive "top layer" or "blocking elements" API.

On the implementer side, the vast majority of work involved in implementing `inert` is a necessary pre-cursor to both <dialog> and more primitive blocking element API implementations, so by implementing inert first, implementers may get useful functionality into the hands of developers sooner while still laying the groundwork for one or both of these more complex APIs.

Interoperability and Compatibility Risk

Low. 

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

crbug.com/692360 

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5703266176335872

Requesting approval to ship?

No

[Dominic Cooney]

This looks like a nice feature and breaks DIALOG's monopoly on this bit of the platform.

On Wed, Feb 15, 2017 at 12:56 PM, 'Alice Boxhall' via blink-dev <blin...@chromium.org> wrote:

Contact email

abox...@chromium.org

Spec

https://github.com/WICG/inert#spec

Summary

The `inert` attribute would allow web authors to mark parts of the DOM tree as inert:

When a node is inert, then the user agent must act as if the node was absent for the purposes of targeting user interaction events, may ignore the node for the purposes of text search user interfaces (commonly known as "find in page"), and may prevent the user from selecting text in that node.

Furthermore, a node which is inert should also be hidden from assistive technology.

Motivation

Developers find themselves in situations where they'd like to be able to mark a part of the page "un-tabbable". Rob Dodson lays out one such example in "Building better accessibility primitives":

One problem: to [achieve a performance optimisation for animation] we must leave the drawer in the DOM at all times. Meaning its focusable children are just sitting there offscreen, and as the user is tabbing through the page eventually their focus will just disappear into the drawer and they won't know where it went. 

See the explainer for more use cases.

 

`inert` would also allow more straightforward polyfilling of both <dialog> and any more primitive "top layer" or "blocking elements" API.

On the implementer side, the vast majority of work involved in implementing `inert` is a necessary pre-cursor to both <dialog> and more primitive blocking element API implementations, so by implementing inert first, implementers may get useful functionality into the hands of developers sooner while still laying the groundwork for one or both of these more complex APIs.

Interoperability and Compatibility Risk

Low. 

This is probably a mix of interop/technical constraints, sorry for the jumble...

My team and I would love to be in the loop on how this interacts with (a) shadow trees; (b) DIALOG; (c) editing, selection, focus, etc. Some things off the top of my head:

I'm a tiny bit curious about how this attribute nests. As you know we have an internal implementation of "inert" today where subtrees (specifically, active dialogs) can be non-inert while the surrounding content is inert. Can the proposal express that? It would be nice if we could subsume DIALOG into one consistent system.

On the other hand as the attribute gets more expressive, the [inert] attribute selector won't be enough; it kind of begs a CSS pseudoclass for it because it won't be possible to write a selector that follows 'inert' accurately as it gets turned on and off at different levels of the tree.

Our implementation doesn't have any signal for inert changing. We rely on things which affect inert triggering style and layout updates and having the inertness change flow through to focus which sets a timer to clear the focused element, which seems a bit convoluted. Similarly editing endures some pain and absurdity from the tangling of editing/style and layout/editability and webkit-user-modify. Since inert interacts with these things we should think hard about how it will work. It would be nice to not make it more difficult to untangle these things later. It's also web visible the timing of things like blur events, etc.

I guess accessibility is the same--dialog changes layout which tickles a11y to re-poll the tree and query inertness, but authors don't have extracurricular hooks like that. In the AOM future will they need to subscribe to inertness changes to react to what subtrees or containers are doing? Or will that all be mediated by the platform?

[PhistucK]

Sorry if I misunderstand you, but your message mentions <dialog> twice in the sense that it does not exist in Chrome (or at least this is my understanding of your message), but it already exists, so there is no need to polyfill anything and while it may be a technical future prequel to the origins of <dialog>, <dialog> exists and is supported already, so you will basically be making one implementation detail/feature of it apply to any other element, right?

Also, is this basically some kind of an advanced form of CSS pointer-events: none;, but in HTML?

Should the user agent style have [inert] { pointer-events: none; }?

I would argue that most of the behavior related changes should be expressible in CSS as well (a CSS property that hides the content from accessibility, for example)...

Can <div aria-hidden="true" style="pointer-events: none;"> (or something similar, my aria skills are very low) be considered as a polyfill for the feature in a way?

Regarding compatibility - have you checked whether the inert attribute is already abused (using a GitHub search, or an HTTPArchive search (this is just an example, unrelated to this intent))?

Regarding interoperability - what do other browser vendor think about the idea?

This is a significant feature in terms of interoperability. One browser will not let the user interact with an element at all, while others will. I think other vendors need to show some interest before you make any significant effort of implementation...

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

Sounds exciting! Fullscreen should also be defined in terms of top layer and ideally other parts of the page should become inert. (This probably doesn't work as it should currently.)

But for this case and dialog, it's everything except a certain element that becomes inert, so could an inert attribute be used to effectively polyfill that behavior?

[Dominic Cooney]

On Wed, Feb 15, 2017 at 3:51 PM, PhistucK <phis...@gmail.com> wrote:

Sorry if I misunderstand you, but your message mentions <dialog> twice in the sense that it does not exist in Chrome (or at least this is my understanding of your message), but it already exists,

DIALOG definitely exists in Chrome, albeit with some bugs. I took that to refer to other browsers: Edge, Firefox and Safari have not shipped DIALOG.

 

so there is no need to polyfill anything and while it may be a technical future prequel to the origins of <dialog>, <dialog> exists and is supported already, so you will basically be making one implementation detail/feature of it apply to any other element, right?

Also, is this basically some kind of an advanced form of CSS pointer-events: none;, but in HTML?

Should the user agent style have [inert] { pointer-events: none; }?

I would argue that most of the behavior related changes should be expressible in CSS as well (a CSS property that hides the content from accessibility, for example)...

Can <div aria-hidden="true" style="pointer-events: none;"> (or something similar, my aria skills are very low) be considered as a polyfill for the feature in a way?

Regarding compatibility - have you checked whether the inert attribute is already abused (using a GitHub search, or an HTTPArchive search (this is just an example, unrelated to this intent))?

Regarding interoperability - what do other browser vendor think about the idea?

This is a significant feature in terms of interoperability. One browser will not let the user interact with an element at all, while others will. I think other vendors need to show some interest before you make any significant effort of implementation...

☆PhistucK

My $0.02, we already have Node::isInert for dialog. I think there's an opportunity here to implement something which, even if we ultimately decide not to ship an inert attribute, makes Blink better. Defining and rationalizing it could fix bugs like CR670130 or CR329410 along the way.

[Dominic Mazzoni]

On Tue, Feb 14, 2017 at 10:52 PM PhistucK <phis...@gmail.com> wrote:

Also, is this basically some kind of an advanced form of CSS pointer-events: none;, but in HTML?

It goes beyond that, because it covers all events, not just pointer events. In particular it makes elements in that subtree not focusable by the keyboard too. There's no existing easy way to accomplish that.

 

Should the user agent style have [inert] { pointer-events: none; }?

My understanding is that would be redundant but not wrong.

 

I would argue that most of the behavior related changes should be expressible in CSS as well (a CSS property that hides the content from accessibility, for example)...

I've seen other proposals to allow all accessibility attributes to be expressible in CSS. It's an interesting idea but I think it's orthogonal.

 

Can <div aria-hidden="true" style="pointer-events: none;"> (or something similar, my aria skills are very low) be considered as a polyfill for the feature in a way?

No, you'd have to make all elements in that subtree not focusable, which isn't really possible because an element with tabindex=-1 can still be programmatically focused. The closest polyfill would be to set the tabindex of anything focusable to -1 and then add an event listener that catches focus inside that subtree and routes it back to some other focusable element.

Regarding your questions about interoperability, I'll let someone else provide a more definitive answer, but there's been discussion and interest from other browsers. Also note that this is an intent to implement, not ship.

[PhistucK]

Comments inline.

☆PhistucK

On Wed, Feb 15, 2017 at 9:42 PM, Dominic Mazzoni <dmaz...@chromium.org> wrote:

On Tue, Feb 14, 2017 at 10:52 PM PhistucK <phis...@gmail.com> wrote:

Also, is this basically some kind of an advanced form of CSS pointer-events: none;, but in HTML?

It goes beyond that, because it covers all events, not just pointer events. In particular it makes elements in that subtree not focusable by the keyboard too. There's no existing easy way to accomplish that.

​Yep, that is the "advanced form" part. :)

Though only certain elements are focusable by default (form related elements) and even they have a disabled attribute, so I would argue that you can accomplish that?

 

 

Should the user agent style have [inert] { pointer-events: none; }?

My understanding is that would be redundant but not wrong.

 

I would argue that most of the behavior related changes should be expressible in CSS as well (a CSS property that hides the content from accessibility, for example)...

I've seen other proposals to allow all accessibility attributes to be expressible in CSS. It's an interesting idea but I think it's orthogonal.

​Yes, it ​is - it just means less magic when the CSS (or other mechanisms) controls the entire behavior and not only part of it. Orthogonal still.

 

Can <div aria-hidden="true" style="pointer-events: none;"> (or something similar, my aria skills are very low) be considered as a polyfill for the feature in a way?

No, you'd have to make all elements in that subtree not focusable, which isn't really possible because an element with tabindex=-1 can still be programmatically focused. The closest polyfill would be to set the tabindex of anything focusable to -1 and then add an event listener that catches focus inside that subtree and routes it back to some other focusable element.

Will doing this on an inert element -

element.dispatchEvent(new FocusEvent("focus"))

Dispatch ​the event (it does so on a disabled <input>)?

I am still not sure why you think that it is not possible to make elements not focusable. I personally think it is very easy to do that for non-form-related elements and a tiny bit of work to do it for form-related elements.

 

Regarding your questions about interoperability, I'll let someone else provide a more definitive answer, but there's been discussion and interest from other browsers. Also note that this is an intent to implement, not ship.

​Of course it is only an intent to implement, but if it is a significant work (no idea), it might be wasted ​time for a feature that (in my opinion, you may enlighten me, of course) is currently very much polyfillable and that does not seem (to me) to be that crucial to the platform anyway.

I guess "significant" was the major point in the original comment. If it is not a significant effort, of course you should do it for experimentation, it was just a conditional advise.

[Alice Boxhall]

On Wed, Feb 15, 2017 at 6:02 PM, Dominic Cooney <domi...@chromium.org> wrote:

On Wed, Feb 15, 2017 at 3:51 PM, PhistucK <phis...@gmail.com> wrote:

Sorry if I misunderstand you, but your message mentions <dialog> twice in the sense that it does not exist in Chrome (or at least this is my understanding of your message), but it already exists,

DIALOG definitely exists in Chrome, albeit with some bugs. I took that to refer to other browsers: Edge, Firefox and Safari have not shipped DIALOG.

Firefox is in the process of implementing: https://bugzilla.mozilla.org/show_bug.cgi?id=1322939

But yes, I did mean other browsers - <dialog> requires a lot of extra work on top of the inert concept, so implementing inert is strictly less work, more primitive, and can potentially get useful functionality to developers quicker.

 

 

so there is no need to polyfill anything and while it may be a technical future prequel to the origins of <dialog>, <dialog> exists and is supported already, so you will basically be making one implementation detail/feature of it apply to any other element, right?

Also, is this basically some kind of an advanced form of CSS pointer-events: none;, but in HTML?

Should the user agent style have [inert] { pointer-events: none; }?

I would argue that most of the behavior related changes should be expressible in CSS as well (a CSS property that hides the content from accessibility, for example)...

Can <div aria-hidden="true" style="pointer-events: none;"> (or something similar, my aria skills are very low) be considered as a polyfill for the feature in a way?

Regarding compatibility - have you checked whether the inert attribute is already abused (using a GitHub search, or an HTTPArchive search (this is just an example, unrelated to this intent))?

Regarding interoperability - what do other browser vendor think about the idea?

This is a significant feature in terms of interoperability. One browser will not let the user interact with an element at all, while others will. I think other vendors need to show some interest before you make any significant effort of implementation...

☆PhistucK

My $0.02, we already have Node::isInert for dialog. I think there's an opportunity here to implement something which, even if we ultimately decide not to ship an inert attribute, makes Blink better. Defining and rationalizing it could fix bugs like CR670130 or CR329410 along the way.

Exactly. I have a CL in progress to implement which makes a minor modification to this method to check the inert attribute, and everything else more or less Just Works.

[Alice Boxhall]

On Wed, Feb 15, 2017 at 5:00 PM, Dominic Cooney <domi...@chromium.org> wrote:

This looks like a nice feature and breaks DIALOG's monopoly on this bit of the platform.

On Wed, Feb 15, 2017 at 12:56 PM, 'Alice Boxhall' via blink-dev <blin...@chromium.org> wrote:

Contact email

abox...@chromium.org

Spec

https://github.com/WICG/inert#spec

Summary

The `inert` attribute would allow web authors to mark parts of the DOM tree as inert:

When a node is inert, then the user agent must act as if the node was absent for the purposes of targeting user interaction events, may ignore the node for the purposes of text search user interfaces (commonly known as "find in page"), and may prevent the user from selecting text in that node.

Furthermore, a node which is inert should also be hidden from assistive technology.

Motivation

Developers find themselves in situations where they'd like to be able to mark a part of the page "un-tabbable". Rob Dodson lays out one such example in "Building better accessibility primitives":

One problem: to [achieve a performance optimisation for animation] we must leave the drawer in the DOM at all times. Meaning its focusable children are just sitting there offscreen, and as the user is tabbing through the page eventually their focus will just disappear into the drawer and they won't know where it went. 

See the explainer for more use cases.

 

`inert` would also allow more straightforward polyfilling of both <dialog> and any more primitive "top layer" or "blocking elements" API.

On the implementer side, the vast majority of work involved in implementing `inert` is a necessary pre-cursor to both <dialog> and more primitive blocking element API implementations, so by implementing inert first, implementers may get useful functionality into the hands of developers sooner while still laying the groundwork for one or both of these more complex APIs.

Interoperability and Compatibility Risk

Low. 

This is probably a mix of interop/technical constraints, sorry for the jumble...

My team and I would love to be in the loop on how this interacts with (a) shadow trees; (b) DIALOG; (c) editing, selection, focus, etc. Some things off the top of my head:

Absolutely. Firstly, to answer a question you ask below: I believe inert should be "no backsies" - once a subtree is inert, you can't make a sub-subtree non-inert. This is mentioned in the "spec gaps" section of the explainer. Happy to discuss reasoning on this but I'll leave it there for now.

So:

(a) inert is inherited into shadow trees, and iframes. (This is also mentioned "spec gaps" section.)

 

(b) excellent question. If a modally shown <dialog> is inside an inert subtree, does it -make a sound- become non-inert? I propose that a dialog inside an inert subtree remains inert, even if it is shown modally.

(c) inert prevents selection and focus. An interesting question is if an inert subtree exists inside a contenteditable subtree, what should happen to it? That I'm not so sure about.

I'm a tiny bit curious about how this attribute nests. As you know we have an internal implementation of "inert" today where subtrees (specifically, active dialogs) can be non-inert while the surrounding content is inert. Can the proposal express that? It would be nice if we could subsume DIALOG into one consistent system.

No, it can't. In order to polyfill <dialog> using inert, you would need to "hoist" the dialog to be a sibling of the main page content.

As I alluded to, I believe there is another missing primitive to explain "dialog" - this would be an API which gives access to the top layer, with an optional "blocking" bit (which I would key on whether a ::backdrop style is provided). I believe inert would be useful in trying to experimentally polyfill this; I don't think we need to do both at once.

 

On the other hand as the attribute gets more expressive, the [inert] attribute selector won't be enough; it kind of begs a CSS pseudoclass for it because it won't be possible to write a selector that follows 'inert' accurately as it gets turned on and off at different levels of the tree.

What use case do you have in mind for selecting for it? I agree it would not be possible to detect in all situations currently - for example, the case where you have the attribute's effects crossing shadow boundaries. However, inert is not intended to have any effect on visual style, and in terms of events and so on, it already affects those, so I'm having trouble coming up with cases where you would need to detect it.

Our implementation doesn't have any signal for inert changing. We rely on things which affect inert triggering style and layout updates and having the inertness change flow through to focus which sets a timer to clear the focused element, which seems a bit convoluted. Similarly editing endures some pain and absurdity from the tangling of editing/style and layout/editability and webkit-user-modify. Since inert interacts with these things we should think hard about how it will work. It would be nice to not make it more difficult to untangle these things later. It's also web visible the timing of things like blur events, etc.

Do you have any specific cases in mind to help think through these issues?

I guess accessibility is the same--dialog changes layout which tickles a11y to re-poll the tree and query inertness, but authors don't have extracurricular hooks like that. In the AOM future will they need to subscribe to inertness changes to react to what subtrees or containers are doing? Or will that all be mediated by the platform?

It should trigger a children changed event on the accessibility tree, much like adding/removing aria-hidden does.

[Dominic Cooney]

Thank you for the detailed replies.

I just want to reiterate that I think implementing this feature is a fine idea. I see little incremental complexity in this over DIALOG.

On Thu, Feb 16, 2017 at 9:01 AM, Alice Boxhall <abox...@google.com> wrote:

On Wed, Feb 15, 2017 at 5:00 PM, Dominic Cooney <domi...@chromium.org> wrote:

This looks like a nice feature and breaks DIALOG's monopoly on this bit of the platform.

On Wed, Feb 15, 2017 at 12:56 PM, 'Alice Boxhall' via blink-dev <blin...@chromium.org> wrote:

Contact email

abox...@chromium.org

Spec

https://github.com/WICG/inert#spec

Summary

The `inert` attribute would allow web authors to mark parts of the DOM tree as inert:

When a node is inert, then the user agent must act as if the node was absent for the purposes of targeting user interaction events, may ignore the node for the purposes of text search user interfaces (commonly known as "find in page"), and may prevent the user from selecting text in that node.

Furthermore, a node which is inert should also be hidden from assistive technology.

Motivation

Developers find themselves in situations where they'd like to be able to mark a part of the page "un-tabbable". Rob Dodson lays out one such example in "Building better accessibility primitives":

One problem: to [achieve a performance optimisation for animation] we must leave the drawer in the DOM at all times. Meaning its focusable children are just sitting there offscreen, and as the user is tabbing through the page eventually their focus will just disappear into the drawer and they won't know where it went. 

See the explainer for more use cases.

 

`inert` would also allow more straightforward polyfilling of both <dialog> and any more primitive "top layer" or "blocking elements" API.

On the implementer side, the vast majority of work involved in implementing `inert` is a necessary pre-cursor to both <dialog> and more primitive blocking element API implementations, so by implementing inert first, implementers may get useful functionality into the hands of developers sooner while still laying the groundwork for one or both of these more complex APIs.

Interoperability and Compatibility Risk

Low. 

This is probably a mix of interop/technical constraints, sorry for the jumble...

My team and I would love to be in the loop on how this interacts with (a) shadow trees; (b) DIALOG; (c) editing, selection, focus, etc. Some things off the top of my head:

Absolutely. Firstly, to answer a question you ask below: I believe inert should be "no backsies" - once a subtree is inert, you can't make a sub-subtree non-inert. This is mentioned in the "spec gaps" section of the explainer. Happy to discuss reasoning on this but I'll leave it there for now.

I've started this thread: https://discourse.wicg.io/t/inert-affecting-subtrees-differently-to-dialog/2018

 

So:

(a) inert is inherited into shadow trees, and iframes. (This is also mentioned "spec gaps" section.)

 

(b) excellent question. If a modally shown <dialog> is inside an inert subtree, does it -make a sound- become non-inert? I propose that a dialog inside an inert subtree remains inert, even if it is shown modally.

(c) inert prevents selection and focus. An interesting question is if an inert subtree exists inside a contenteditable subtree, what should happen to it? That I'm not so sure about.

An analogy here might be in user-select: none starts to apply to a subtree. yoichio, yosin, WDYT?

 

I'm a tiny bit curious about how this attribute nests. As you know we have an internal implementation of "inert" today where subtrees (specifically, active dialogs) can be non-inert while the surrounding content is inert. Can the proposal express that? It would be nice if we could subsume DIALOG into one consistent system.

No, it can't. In order to polyfill <dialog> using inert, you would need to "hoist" the dialog to be a sibling of the main page content.

I see. This would affect selectors. Then there's the niggling detail of BODY; I think BODY is inert when a dialog is shown, but would be non-inert in the polyfill.

 

As I alluded to, I believe there is another missing primitive to explain "dialog" - this would be an API which gives access to the top layer, with an optional "blocking" bit (which I would key on whether a ::backdrop style is provided). I believe inert would be useful in trying to experimentally polyfill this; I don't think we need to do both at once.

 

On the other hand as the attribute gets more expressive, the [inert] attribute selector won't be enough; it kind of begs a CSS pseudoclass for it because it won't be possible to write a selector that follows 'inert' accurately as it gets turned on and off at different levels of the tree.

What use case do you have in mind for selecting for it? I agree it would not be possible to detect in all situations currently - for example, the case where you have the attribute's effects crossing shadow boundaries. However, inert is not intended to have any effect on visual style, and in terms of events and so on, it already affects those, so I'm having trouble coming up with cases where you would need to detect it.

The use case is just that--you want to make a subtree inert and change the presentation too, similar to the disabled attribute for form elements and the :disabled selector.

 

Our implementation doesn't have any signal for inert changing. We rely on things which affect inert triggering style and layout updates and having the inertness change flow through to focus which sets a timer to clear the focused element, which seems a bit convoluted. Similarly editing endures some pain and absurdity from the tangling of editing/style and layout/editability and webkit-user-modify. Since inert interacts with these things we should think hard about how it will work. It would be nice to not make it more difficult to untangle these things later. It's also web visible the timing of things like blur events, etc.

Do you have any specific cases in mind to help think through these issues?

yosin is probably the best mind to ponder editing edge cases.

I've been reading the HTML spec and the "focus fixup rule three" already covers inert-ness and inert attribute setting may just need to trigger focus update steps. I guess investigating if DIALOG is triggering that sanely would be interesting. The focus clearing in style recalc I was complaining about may be an entirely separate thing.