HTML: inert attribute

[annevk]

Request for Mozilla Position on an Emerging Web Specification

• Specification or proposal URL: Re add inert whatwg/html#4288 & https://github.com/WICG/inert/blob/master/explainer.md
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):

Other information

The inert attribute allows for marking a section of a document as not being able to receive UI events. Those will go to the nearest ancestor instead.

[bzbarsky]

@smaug---- @masayuki-nakano @MatsPalmgren

[alice]

events ... will go to the nearest ancestor instead.

Not quite true: they will go to the nearest ancestor which would be found by hit-testing at the point that the event was generated at.

http://web-platform-tests.live/inert/inert-retargeting.tentative.html demonstrates this behaviour - try in Chrome canary/dev channel with --enable-experimental-web-platform-features enabled.

[smaug----]

So it is like pointer-events: none; for hit-testing?

[emilio]

So the explainer says:

Temporarily offscreen/hidden content
As discussed in the article, there are a range of circumstances in which case it's desirable to add content to the DOM to be rendered but remain offscreen.
In these cases, without inert, authors are forced to choose between an accessible experience for keyboard and assistive technology users, or the factors (such as performance) which make offscreen rendering desirable - or, performing all the contortions necessary to keep the offscreen content functionally "inert".

Gecko still has to this day a -moz-user-focus CSS property that somewhat resembles this draft of CSS-UI, but with additional values none and ignore. I think (from quick testing) these days they cannot override the tab navigation behavior anymore, but I suspect they could at some point, or that could've been the intention. Maybe Mats or someone else who has been more at Mozilla recalls more about the origin of these values.

Has such an approach being considered? Over-all it'd seem a bit more consistent with the way e.g., user-select or pointer-events work.

[emilio]

Then inert maybe could be just defined with something like:

[inert] {
  user-focus: none !important;
  user-select: none !important;
  pointer-events: none !important;
}

Also, from what I can see inert also changes the behavior of some selection APIs, why is that? I'd expect inert to not affect any API, only user-facing actions.

[emilio]

Also, inert seems to be using shadow-including descendants, rather than flat-tree descendants, right? That means that if I use <slot inert>, the slotted children should not be "in an inert subtree", but the fallback children would, right? That seems a bit unfortunate to me.

[alice]

So it is like pointer-events: none; for hit-testing?

Not exactly. pointer-events: none makes the element ignored for hit testing altogether; this is more subtle, as it precludes events going to non-ancestors, or to ancestors which would not be returned from a hit test at that point.

[alice]

Gecko still has to this day a -moz-user-focus CSS property ... Has such an approach being considered? Over-all it'd seem a bit more consistent with the way e.g., user-select or pointer-events work.

Here's what we have in the explainer on that topic:

inert encompasses the behaviour of at least two other things which are CSS properties - pointer-events: none [actually no longer true anyway] and user-select: none, plus another attribute, aria-hidden. These behaviours, along with the currently near-impossible to achieve behaviour of preventing tabbing/programmatic focus, are very frequently applied together (or if one, such as aria-hidden, is omitted, it is more often through lack of awareness than deliberate).

There is scope for a more primitive CSS property to "explain" the ability of inert to prevent focus, however that could easily coexist with the inert attribute.

[emilio]

Is the shadow dom behavior described in #174 (comment) intentional? It seems as a web component author it may be reasonable to try to use <slot inert>, and that would unexpectedly not work at all. Also, that means that this is observably different from how a CSS property would work (which would work on the flattened tree).

[alice]

Is the shadow dom behavior described in #174 (comment) intentional?

I need to look into this more, but you're probably right that it should use the flat tree rather than the shadow-including tree. Thanks for catching!

[smaug----]

The proposal looks reasonable to me, but the pr needs to be updated (and some more wpt tests added).

[alice]

the pr needs to be updated

I was just looking at this now. I think the only update required (other than rebasing) is modifying the language noted in #174 (comment) - however, I'm not sure exactly how to word it.

The language in question is:

While an element has an inert attribute, the user agent must mark that element and all its shadow-including descendants as inert.

I agree that this is not quite right, but I don't see any other examples of referring directly to the flat tree. @emilio do you have any suggestions on how to word this?

some more wpt tests added

@smaug---- could you clarify what additional tests you'd like to see beyond the suite in http://web-platform-tests.live/inert/ ?

[emilio]

I agree that this is not quite right, but I don't see any other examples of referring directly to the flat tree. @emilio do you have any suggestions on how to word this?

There are a few references to https://drafts.csswg.org/css-scoping/#flat-tree and such. Not sure if it's ok to reference that spec from html, or whether that definition should be moved to somewhere else.

[smaug----]

Should probably discuss about the actual spec issue in whatwg, not in this standards-position issue.

[alice]

@smaug---- Do you think you could comment on what additional tests you'd like to see?

[smaug----]

@alice there should be more tests covering inert handling in shadow DOM.
(But the actual behavior should be discussed in the spec bug. Need to figure out the right behavior so that we don't leak too much information about existence of shadow DOM, but still keep the API working in some sane way.)

[alice]

@smaug---- There are two tests currently covering how inert propagates through Shadow DOM/flat tree:
https://github.com/web-platform-tests/wpt/blob/master/inert/inert-in-shadow-dom.tentative.html
https://github.com/web-platform-tests/wpt/blob/master/inert/inert-on-slots.tentative.html

I'd love it if you can take a look and tell me whether you see any cases I haven't covered.

As far as leaking information goes, I'm not clear on the concern there. Leaving aside that it would be difficult to deduce that an element other than the ancestor with the inert attribute is actually part of an inert subtree in the first place, what are the actual ramifications of being able to deduce that a parent element has some shadow content?

[alice]

@smaug---- Just bumping the above comment.

[smaug----]

@alice
Looks like there are quite good tests now. One thing I'd like to see is a test where it is text node which is slotted and then slot or something in shadow dom which is inert. Which element should get the event?
Another case is nested shadow DOM.

[alice]

One thing I'd like to see is a test where it is text node which is slotted and then slot or something in shadow dom which is inert. Which element should get the event?

So sorry, I couldn't quite follow that. Any chance you could make a quick code example of what you mean?

Another case is nested shadow DOM.

Good point, will add a test for that.

[smaug----]

Pseudo code
<div id="host">some text</div>
host.attachShadow({mode: "open"}).innerHTML = <span><slot></slot></span>

And then make either span or slot inert and fire some event on top of 'some text'

[alice]

Thanks for the example!

[annevk]

Would the correct assessment from the comments be that we should consider this worth prototyping? Have the proposal and tests settled?

[smaug----]

Worth prototyping sounds good to me.

[emilio]

Yeah, it sounds fair, but I have one question while I thought a bit more about this @alice:

I think the use cases for off-screen content not being tabbable and such are better addressed by visibility: hidden, fwiw, which does behave like you want there (both preventing focusability and hiding it for a11y). I agree that as a web developer that may be a bit obscure perhaps, but I'm not sure that's quite enough of an issue to introduce this feature.

It seems like the other use cases in the explainer want kind of the opposite of inert (as in, make one particular part of the page interactive, rather than non-interactive, making the rest automatically "inert"). But I may be misunderstanding some? And I guess that's a bit harder to define, as you need to deal with the attribute being in multiple subtrees, which is easier than with this hypothetical opposite thing.

Could you clarify whether the above bits are true and / or I am misunderstanding something (which is definitely possible)? If I'm not missing much, maybe the explainer should elaborate a bit on the reasoning behind the design? Otherwise I can mostly try to guess that it is due to ease of implementation / specification, but regardless of whether it's that or another thing it should probably be spelled out.

Thanks so much.

[robdodson]

I think the use cases for off-screen content not being tabbable and such are better addressed by visibility: hidden, fwiw, which does behave like you want there (both preventing focusability and hiding it for a11y). I agree that as a web developer that may be a bit obscure perhaps, but I'm not sure that's quite enough of an issue to introduce this feature.

I think the primary reason we thought inert would be useful in this case has to do with animation and compositor layers. For offscreen hamburger menus, you often want to animate them into position as soon as the user presses the button. Since that's just a translation, you can promote that element to its own compositor layer to make the animation as efficient as possible.

However, if you set that element to visibility: hidden I believe it will remove that compositor layer. If the element is sufficiently complex (consider the hamburger menu on m.facebook.com) then it may be expensive trying to paint it, promote it to a layer, and animate it when the user presses the hamburger or tries to swipe it on screen. If, however, it's inert, then it can remain on its layer but still be offscreen and ready to animate at a moment's notice.

[alice]

Regarding the use cases for the "opposite of inert" primitive - you're right that it's largely around ease of specification, combined with the fact that there is a use case for inert on its own.

This is actually addressed in the explainer (albeit somewhat non-obviously) in the "Wouldn't this be better as" section:

• blockingElements?

  blockingElements (or, potentially, a single blockingElement) represents roughly the opposite use case to inert: a per-document, single element which blocks the document, analogous to the blocking behaviour of a modal dialog.

  It's not always the case that we will want a single subtree to be non-inert. Ideally, we would have both concepts available; however, inert allows reasonable approximation of blockingElements whereas the reverse is not true.

  • To approximate a blockingElement using inert, it's most straightforward to insert a non-inert element as a sibling element to the main page content, and then use inert to mark the main page content as inert. More generally, all siblings of the desired "blocking" element, plus all siblings of all of its ancestors, could be marked inert.

[emilio]

I think the primary reason we thought inert would be useful in this case has to do with animation and compositor layers. For offscreen hamburger menus, you often want to animate them into position as soon as the user presses the button. Since that's just a translation, you can promote that element to its own compositor layer to make the animation as efficient as possible.

I don't think this argument applies. First, not all compositors use layers, fwiw. But also if the menu is off-screen and not animating, browsers usually won't promote them to GPU surfaces anyway to save GPU memory, which is a scarce resource. So the menu will only be promoted to the GPU once you start animating it, and at that point you no longer need visibility: hidden.

Regarding the use cases for the "opposite of inert" primitive - you're right that it's largely around ease of specification, combined with the fact that there is a use case for inert on its own.

What is the use case for inert on its own? What @robdodson mentioned?

[emilio]

Btw, another thing that was unclear to me, while I re-read the thread, just to confirm... You said:

Not exactly. pointer-events: none makes the element ignored for hit testing altogether; this is more subtle, as it precludes events going to non-ancestors, or to ancestors which would not be returned from a hit test at that point.

But that is exactly the behavior I see with a simple test-case like this:

<!doctype html>
<style>
  .none {
    pointer-events: none;
    width: 100px;
    height: 100px;
  }
</style>
<div id="ancestor">
  <div class="none">
    <div id="child">Child</div>
  </div>
</div>
<script>
  document.addEventListener("click", function(e) {
    console.log(e.target);
  });
</script>

(i.e., clicks on Child go to #ancestor, which IIUC is basically the proposed behavior here).

So the only difference that I'm aware of at this point is that with pointer-events children can opt back into it, right? Is that the subtlety you meant? Or am I missing something else?

[emilio]

Or you mean that with inert there should be no event at all being dispatched when you click on Child?

[alice]

What is the use case for inert on its own? What @robdodson mentioned?

The explainer lists the following, in addition to the use case Rob discussed:

• A slide show or "cover flow" style carousel may have non-active items partially visible, as a preview - they may be transformed or partially obscured to indicate that they are non-interactive.

• Form content which is not currently relevant, e.g. fading out and disabling the "Shipping Address" fields when the "Same as billing address" checkbox has been checked.

• Disabling the entire UI while in an inconsistent state, such as showing a throbber/loading bar during unexpectedly slow loading.

---

So the only difference that I'm aware of at this point is that with pointer-events children can opt back into it, right? Is that the subtlety you meant? Or am I missing something else?

My wording was awkward: by "this" I meant the behaviour specced for inert.

pointer-events: none makes the element "transparent" for hit testing. If the element is absolute positioned over a non-ancestor element, any event targeted based on hit testing will land on the non-ancestor element.

inert, on the other hand, doesn't allow events to go to the non-ancestor element. This WPT test demonstrates the behaviour I'm describing.

---

To turn the question back around: is there any harm you could imagine from shipping the inert attribute before we start the work of figuring out the complementary "blocking elements" or "top layer" API?

[robdodson]

I don't think this argument applies. First, not all compositors use layers, fwiw. But also if the menu is off-screen and not animating, browsers usually won't promote them to GPU surfaces anyway to save GPU memory, which is a scarce resource. So the menu will only be promoted to the GPU once you start animating it, and at that point you no longer need visibility: hidden.

I'll need to test this again. If I recall I tested it years ago and Chrome's behavior was to keep the layer when it was offscreen and to remove it if it had visibility: hidden. But I can double check.

[robdodson]

It looks like Chrome keeps the layer around if the element is offscreen, and removes the layer if the element is offscreen with visibility set to hidden.

Element is offscreen. No visibility property set.

Element is offscreen. Visibility is set to hidden.

Here's the HTML I used:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>Layer test</title>
  <style>
    body {
      height: 100vh;
      margin: 0;
    }
    
    .layer {
      width: 50%;
      height: 100vh;
      background: red;
      will-change: transform;
      transform: translateX(-110%);
      //visibility: hidden;      
    }
  </style>
</head>
<body>
  <div class="layer">
    hello world
  </div>
</body>
</html>

I used the Layers panel in Chrome DevTools to check for the existence of layers:

I'm not a GPU expert so I may be misinterpreting the results.

[emilio]

Note that layers in chrome as I understand it are not necessarily always composited (so, regardless whether there's a "layer", it's I think not necessarily a GPU surface). Not clear to me that the devtools inspector is the best way to argue here. Would probably be better to confirm with a Chromium engineer whether they promote to GPU surfaces stuff that's offscreen and is not animating at the moment. I guess will-change transform could serve as a hint to do that... I'd still be mildly surprised that they'd do that for every element that has will-change: transform even if off-screen, specially on android, where GPU memory can be way more scarce.

But anyhow that's not the point, I digress... The definition of will-change doesn't guarantee anything... I don't think it's great to argue based on the layerization heuristics of one browser engine at one particular point in time. At least not when discussing standards that should apply to all web engines and all platforms.

Form content which is not currently relevant, e.g. fading out and disabling the "Shipping Address" fields when the "Same as billing address" checkbox has been checked.

(not that it matters much, fwiw, but isn't <input disabled> / <fieldset disabled> / etc a better way to do that? It prevents focusability as well)

inert, on the other hand, doesn't allow events to go to the non-ancestor element. This WPT test demonstrates the behaviour I'm describing.

I see, thank you. Is there any reason you chose this behavior in particular? Why is it more useful than the current pointer-events behavior? Also, should this particular behavior really be tied to inert, rather than being another pointer-events value? Generally having inputs to layout / graphics / hit-testing that are not given via CSS is a bit of a smell / layering violation IMHO...

To turn the question back around: is there any harm you could imagine from shipping the inert attribute before we start the work of figuring out the complementary "blocking elements" or "top layer" API?

Well, not particularly other than the risk of shipping something that adds a bunch of complexity / subtleties for both authors and implementors, but which we don't know whether it's going to be the final solution for the problems we're trying to solve. It might be ok if inert was clearly a primitive that we need for those things, but it's not clear to me how to cleanly implement blocking elements, etc on top of inert (because they want fundamentally the opposite).

I also think that the design could be a bit cleaner / simpler if the primitives inert itself needs were less special. I feel (though I guess not all that strongly) that you should probably be able to get the same hit-testing / selection behavior as you're proposing for inert via CSS. Then the inert behavior could be described in much more simple terms.

[alice]

Is there any reason you chose this behavior in particular? Why is it more useful than the current pointer-events behavior?

The current pointer-events behaviour means that if an element is visually on top of another element, you can "click through" the element to one which is behind, even if you can't see it.

pointer-events was originally intended for SVG, as far as I know, to allow authors to designate which part of a shape was intended to be interactive.

it's not clear to me how to cleanly implement blocking elements, etc on top of inert (because they want fundamentally the opposite)

They need the same concept of "inertness" (which is shared by the <dialog> element as well). inert the attribute just exposes that on a subtree.

you should probably be able to get the same hit-testing / selection behavior as you're proposing for inert via CSS

Can you expand on why? Why do you feel that CSS the right place for this to live?

In any case, I would be happy with it also being in CSS, but as I said in the explainer:

inert encompasses the behaviour of at least two other things which are CSS properties - pointer-events: none and user-select: none, plus another attribute, aria-hidden. These behaviours, along with the currently near-impossible to achieve behaviour of preventing tabbing/programmatic focus, are very frequently applied together (or if one, such as aria-hidden, is omitted, it is more often through lack of awareness than deliberate).

There is scope for a more primitive CSS property to "explain" the ability of inert to prevent focus, however that could easily coexist with the inert attribute.

In particular, the combination of behaviours is important; it's very likely that authors would apply only a subset of the necessary primitives.

[emilio]

The current pointer-events behaviour means that if an element is visually on top of another element, you can "click through" the element to one which is behind, even if you can't see it.

Sure.

pointer-events was originally intended for SVG, as far as I know, to allow authors to designate which part of a shape was intended to be interactive.

Yeah, though people use it for other things all the time, and it does work for non-SVG.

They need the same concept of "inertness" (which is shared by the <dialog> element as well). inert the attribute just exposes that on a subtree.

Sure, but inert-the-attribute is not useful for <dialog>. The concept of "inert node" is.

Can you expand on why? Why do you feel that CSS the right place for this to live?

Because it seems really odd to have things affect hit-testing without authors being able to query it, or override it, etc. It also more generally feels wrong for hit-testing to depend on the DOM, it should ideally just depend on the layout tree + css.

In particular, the combination of behaviours is important

Sure, I agree that the combination is important, but the hit-testing behavior seems potentially useful outside of inert (and so does the selection behavior, which is already exposed via CSS). I don't know why we should have two switches, one based on the DOM and one based on CSS for these, when it's relatively straight-forward to define the attribute's behavior in terms of CSS.

it's very likely that authors would apply only a subset of the necessary primitives.

I see, so your worry is the one of authors potentially misusing the primitives if we only expose them via CSS? I'm not sure to what extent I share that concern, but in any case that seems somewhat tangential. To be clear, what I'm suggesting is that the definition of the inert attribute (or inert nodes in general) should probably work in a way that causes the computed style of inert nodes to have user-select: none and pointer-events: <something-that-doesnt-exist-today> in it, rather than being fully magic.

[Malvoz]

inert (or pointer-events with a new value) as a CSS property sounds similar to box-suppress which @rachelandrew explains in https://rachelandrew.co.uk/archives/2016/07/22/the-proposed-box-suppress-property/.

Also general focusability in CSS has been proposed in w3c/csswg-drafts#1748 and w3c/csswg-drafts#3379. Not sure if this adds much value to your discussion but I couldn't help noticing some overlap in older related issues.

[emilio]

box-suppress is different (prevents constructing boxes, which is basically display: none but without overriding display), however the other links are indeed related to this, and pretty useful. Thank you!

[alice]

Sure, but inert-the-attribute is not useful for <dialog>. The concept of "inert node" is.

I wasn't arguing otherwise.

inert the attribute is useful for approximating the behaviour of <dialog>, and other things which need similar behaviour. It allows you to opt in to inertness without opting in to all of <dialog>'s behaviour, and with minimal spec and implementation requirements.

Because it seems really odd to have things affect hit-testing without authors being able to query it, or override it, etc.

You can't query or override display: none on an ancestor, either. Nor can you query or override whether something is blocked by a modal dialog. Is there a more specific issue than "it seems odd"?

Also, it not being possible to override it is a deliberate feature: it makes it simple to reason about what happens if you use inert on a node. If it could be overridden, some code not under the control of the author who added the attribute could accidentally override it for a subtree.

To be clear, what I'm suggesting is that the definition of the inert attribute (or inert nodes in general) should probably work in a way that causes the computed style of inert nodes to have user-select: none and pointer-events: <something-that-doesnt-exist-today> in it, rather than being fully magic.

Once again: I'm not opposed to working towards this, but without blocking shipping inert on it. I don't believe that we should always aim to ship (or even spec) the lowest layer first.

You may not be concerned about authors failing to apply all of the necessary properties, but I am. I see this over and over again with authors doing just enough to handle the use case for sighted users using a pointing device, and creating a broken experience for everyone else.

[bkardell]

could accidentally override it for a subtree.

Yeah, just to elaborate some more - this was very conscious. display none, visibility hidden, aria hidden, these apply to the subtree, you can't opt out further down... Same needs to be here or it doesn't make a lot of sense. Part of the goal here in our minds was that this is a level up:. Authors already have plenty of low-level knobs that can be turned, but for this kind of problem its a matter of juggling lots of knobs and it's easy to get wrong (or just not do it).

To be clear, what I'm suggesting is that the definition of the inert attribute (or inert nodes in general) should probably work in a way that causes the computed style of inert nodes to have user-select: none and pointer-events: in it, rather than being fully magic

Sure. I'm pro-exploring this too! Authors really ultimately should have access to the knobs we can expose and explanations of magic we can explain. Like @alice though, I don't think it actually needs to block anything here on this point if we've split the problem well. Is there a very particular concern that you have here that leads you to believe otherwise? Authors need a higher tool for this pattern, or we can't expect it to be very common that they get it right.

Also general focusability in CSS has been proposed in w3c/csswg-drafts#1748 and w3c/csswg-drafts#3379. Not sure if this adds much value to your discussion but I couldn't help noticing some overlap in older related issues.

I'll just add that these are by no means done things, or solved. Focus has a few decades worth of troubling bits we're actively trying to work though - the focus metabug has a good starting list. Concerns about this have been brought up and discussed several times, and even a counter proposal leading to a larger discussion last year in Toronto during CSSWG. So, all I am saying there is - we should take those with a very healthy grain of salt.

[alice]

#174 (comment) seems to suggest that the consensus was that this is worth prototyping, but I don't see that on https://mozilla.github.io/standards-positions/. Has the position changed?

[emilio]

You can't query or override display: none on an ancestor, either. Nor can you query or override whether something is blocked by a modal dialog. Is there a more specific issue than "it seems odd"?

That is fine. You can specify a pointer-events value that makes hit-testing invisible for all descendants. I don't see how that's a problem. My problem is with this hit testing behavior depending completely on the DOM, without going through CSS.

, just to elaborate some more - this was very conscious. display none, visibility hidden, aria hidden, these apply to the subtree, you can't opt out further down

That is... not true? visibility: visible stuff under a visibility: hidden subtree definitely shows up. display: none is special, but again you can override and query the display property value on the display: none subtree root.

Once again: I'm not opposed to working towards this, but without blocking shipping inert on it. I don't believe that we should always aim to ship (or even spec) the lowest layer first.

I guess I kinda disagree on what the lowest layer is, but... :)

[emilio]

#174 (comment) seems to suggest that the consensus was that this is worth prototyping, but I don't see that on https://mozilla.github.io/standards-positions/. Has the position changed?

No, I think we just need to reflect it on the repo, I'll send a PR for that :)

[emilio]

Is there a very particular concern that you have here that leads you to believe otherwise?

(Sorry, I had missed this question...)

Well, my main concern is that how this works is totally observable if you implement it one way or another. So I'd rather get it right from the beginning.

[emilio]

Ok, I filed whatwg/html#5650 with a (hopefully good) summary of the current discussion. I think we should keep discussing the technical details there.

It also has a more concrete proposal of what I've talked about up-thread, so hopefully my opinion is a bit better reflected there as well. Per discussion with Anne, this is something that we generally want to support, but we'd like the design to be fully fleshed out before committing to it.

[dbaron]

So in #371 @tantek asked whether we should block on the resolution of whatwg/html#5650.

While I think @emilio is correct that this probably should have been designed so that it affects computed style of cursor, pointer-events, and probably user-select... I think you could also say the same for the <dialog> element, and it seems like that's not how the <dialog> element (which uses the same definition of inertness) works. And there's value in being consistent with the <dialog> element, which has been in the spec for a long time (at least since before this issue was filed). And I also don't think it's 100% clear what the right behavior is; there are likely use cases going both ways. Script looking at computed styles might want to understand inert-ness, or script running on something inside of an inert subtree might want to operate on the styles that would be present when the subtree is not inert. (I'd be interested to see documentation of the primary use cases for getComputedStyle -- that might help us answer which use case is more important.)

So given that <dialog> has already been specified and shipped in Chromium (although not other browsers) for a long time, I think it probably makes sense to look at changing the details of the mechanism underlying both it and inert as a separate discussion from what we think of inert, which seems like a valuable feature that has real user benefits.