Intent to Ship: inert attribute

[Alice Boxhall]

Contact emails

abox...@chromium.org

Explainer

https://github.com/WICG/inert/blob/main/explainer.md

Specification

https://github.com/whatwg/html/pull/4288

API spec

Yes

Design docs

https://github.com/WICG/inert#tldr
https://discourse.wicg.io/t/inert-attribute/1838/
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement

Summary

The inert attribute allows 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.

Blink component

Blink>HTML

Search tags

inert, focus, accessibility, keyboard, events, pointer

TAG review

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: Worth prototyping (https://mozilla.github.io/standards-positions/#inert-attr)

WebKit: No signal

Web developers: Positive (https://www.a11yproject.com/announcements/2020-08-19-lets-support-inert/)

Is this feature fully tested by web-platform-tests?

Yes

Tracking bug

http://crbug.com/692360

Sample links

https://wicg.github.io/inert/demo/

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5703266176335872

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/N--HhuYFJQI/m/bmwhhHDZCQAJ

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Tue, Mar 30, 2021 at 5:58 AM Alice Boxhall <abox...@chromium.org> wrote:

Contact emails

abox...@chromium.org

Explainer

https://github.com/WICG/inert/blob/main/explainer.md

Specification

https://github.com/whatwg/html/pull/4288

API spec

Yes

Design docs

https://github.com/WICG/inert#tldr
https://discourse.wicg.io/t/inert-attribute/1838/
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement

Summary

The inert attribute allows 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.

Blink component

Blink>HTML

Search tags

inert, focus, accessibility, keyboard, events, pointer

TAG review

https://github.com/w3ctag/design-reviews/issues/610 right?

 

TAG review status

Pending

Seems like it was recently closed, with the TAG happy about it. 

Risks

Interoperability and Compatibility

Gecko: Worth prototyping (https://mozilla.github.io/standards-positions/#inert-attr)

WebKit: No signal

Could you ask for a signal? https://bit.ly/blink-signals

 

Web developers: Positive (https://www.a11yproject.com/announcements/2020-08-19-lets-support-inert/)

Is this feature fully tested by web-platform-tests?

Yes

Tracking bug

http://crbug.com/692360

Sample links

https://wicg.github.io/inert/demo/

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5703266176335872

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/N--HhuYFJQI/m/bmwhhHDZCQAJ

This intent message was generated by Chrome Platform Status.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMQHGLzU8G2HpCmNsr63qaYePWWv_m%3DFuVD1ytquESLvTLqp0w%40mail.gmail.com.

[Alice Boxhall]

 Oops yes, thanks for catching that!

 

Risks

Interoperability and Compatibility

Gecko: Worth prototyping (https://mozilla.github.io/standards-positions/#inert-attr)

WebKit: No signal

Could you ask for a signal? https://bit.ly/blink-signals

Will do.

[Yoav Weiss]

On Tuesday, March 30, 2021 at 5:58:24 AM UTC+2 A Boxhall wrote:

Contact emails

abox...@chromium.org

Explainer

https://github.com/WICG/inert/blob/main/explainer.md

Specification

https://github.com/whatwg/html/pull/4288

Any particular reason the PR hasn't landed? It seems like there's support from Mozilla

Also, Mozilla folks mentioned 2 blocking issues for shipping this by default. Are those issues blocking the PR? How did we handle those issues?

[PhistucK]

Is this something like (CSS) -

[inert]

{

 pointer-events: none;

 user-select: none;

}

Plus no-keyboard-access and find-in-page-invisibility?

Will there be a way to override it (a-la-Alt + drag to select text in a link without activating a link)?

☆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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org.

[Alex Russell]

Glad to see this moving forward. LGTM1

[Mike West]

I also think this looks quite reasonable, and I think it's a good addition to the platform. That said, I think Yoav's questions about the details and Mozilla's approach are good ones. Alice, how do you think we should handle them?

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org.

[Alice Boxhall]

Sorry for putting off replying to this, I've been trying to weigh up what I actually think about it all.

On Fri, Apr 9, 2021 at 4:13 AM Mike West <mk...@chromium.org> wrote:

I also think this looks quite reasonable, and I think it's a good addition to the platform. That said, I think Yoav's questions about the details and Mozilla's approach are good ones. Alice, how do you think we should handle them?

-mike

On Thu, Apr 8, 2021 at 12:45 AM 'Alex Russell' via blink-dev <blin...@chromium.org> wrote:

Glad to see this moving forward. LGTM1

On Saturday, April 3, 2021 at 7:20:05 AM UTC-7 PhistucK wrote:

Is this something like (CSS) -

[inert]

{

 pointer-events: none;

 user-select: none;

}

Plus no-keyboard-access and find-in-page-invisibility?

And not exposed to assistive technology APIs, similar to the way we do when a node is inert because of a blocking modal dialog (like aria-hidden=true).

As currently specced, it's not identical to `pointer-events: none`, because `pointer-events: none` is equivalent to "ignore the element when hit testing". That makes me uneasy, because if the element is opaque then the user has no way of knowing what they're clicking on, which seems like a potentially poor experience.

So as currently specced, it retargets pointer events such that only ancestors of the inert element are eligible as targets.

However, it's been pointed out that this means that if the element is transparent, it's a potentially poor experience if there are elements that are intended to be interactive behind the inert element. So I'm not really sure what the best solution is here.

 

Will there be a way to override it (a-la-Alt + drag to select text in a link without activating a link)?

There isn't currently; that seems like something that could come later if it turns out to be annoying not to have it.

 

☆PhistucK

On Thu, Apr 1, 2021 at 9:15 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Tuesday, March 30, 2021 at 5:58:24 AM UTC+2 A Boxhall wrote:

Contact emails

abox...@chromium.org

Explainer

https://github.com/WICG/inert/blob/main/explainer.md

Specification

https://github.com/whatwg/html/pull/4288

Any particular reason the PR hasn't landed? It seems like there's support from Mozilla

Also, Mozilla folks mentioned 2 blocking issues for shipping this by default. Are those issues blocking the PR? How did we handle those issues?

I'm not sure why the PR hasn't landed.

One issue is how/whether to expose inert subtrees to assistive technology. As implemented right now, it's the same as aria-hidden. The proposal is to extend AT APIs to add an extra "inert" state. That doesn't seem like it should block shipping; not exposing inert nodes to AT APIs will almost always be the best thing to do, and it's more or less what we do for nodes made inert by a blocking modal dialog. Being able to expose inert nodes to AT and have the AT decide whether/how to expose them to the user would be a nice feature to add, but I don't think it's critical.

The other issue is whether inert should be implemented/specced in terms of certain CSS properties (more or less the ones mentioned above), and whether that should be detectable by authors via matches(). I have asked whether there are any specific scenarios where this would be useful, but as far as I know nobody has proposed any, so it doesn't seem like a blocking issue to me either, particularly when I'm not sure whether the behaviour should closely match pointer-events: none.

[Manuel Rego Casasnovas]

I'm also supportive of "inert", it's nice to see it coming to the browsers.

I'm curious about the interop status, the feature hasn't shipped in
Firefox yet so I'm not sure if this reflects the reality or not:
https://wpt.fyi/results/inert?label=experimental&label=master&aligned
Are Chromium and Firefox implementations interoperable?

Apart from that, we haven't asked for signals to WebKit yet
(https://bit.ly/blink-signals) unless I missed the mail.

Cheers,
Rego

> /is/ transparent, it's a potentially poor experience if there are

> elements that are intended to be interactive behind the inert element.
> So I'm not really sure what the best solution is here.
>  
>
>
> Will there be a way to override it (a-la-Alt + drag to
> select text in a link without activating a link)?
>
>
> There isn't currently; that seems like something that could come later
> if it turns out to be annoying not to have it.
>  
>

> ☆*PhistucK*

>
>
> On Thu, Apr 1, 2021 at 9:15 AM Yoav Weiss
> <yoav...@chromium.org> wrote:
>
>
>
> On Tuesday, March 30, 2021 at 5:58:24 AM UTC+2 A Boxhall
> wrote:
>
>
> Contact emails
>
> abox...@chromium.org
>
>
> Explainer
>
>
> https://github.com/WICG/inert/blob/main/explainer.md
> <https://github.com/WICG/inert/blob/main/explainer.md>
>
>
> Specification
>
> https://github.com/whatwg/html/pull/4288
> <https://github.com/whatwg/html/pull/4288>
>
>
> Any particular reason the PR hasn't landed? It seems
> like there's support from Mozilla
> Also, Mozilla folks mentioned

> <https://github.com/whatwg/html/pull/4288#issuecomment-684009827>

> 2 blocking issues for shipping this by default. Are
> those issues blocking the PR? How did we handle those
> issues?
>
>
> I'm not sure why the PR hasn't landed.
>
> One issue is how/whether to expose inert subtrees to assistive
> technology. As implemented right now, it's the same as aria-hidden. The
> proposal is to extend AT APIs to add an extra "inert" state. That
> doesn't seem like it should block shipping; not exposing inert nodes to
> AT APIs will almost always be the best thing to do, and it's more or
> less what we do for nodes made inert by a blocking modal dialog. Being
> able to expose inert nodes to AT and have the AT decide whether/how to
> expose them to the user would be a nice feature to add, but I don't
> think it's critical.
>
> The other issue is whether inert should be implemented/specced in terms
> of certain CSS properties (more or less the ones mentioned above), and
> whether that should be detectable by authors via matches(). I have asked
> whether there are any specific scenarios where this would be useful, but
> as far as I know nobody has proposed any, so it doesn't seem like a
> blocking issue to me either, particularly when I'm not sure whether the
> behaviour should closely match pointer-events: none.
>  
>
>
>
>
> API spec
>
> Yes
>
>
> Design docs
>
>
> https://github.com/WICG/inert#tldr

> <https://github.com/WICG/inert#tldr>
> https://discourse.wicg.io/t/inert-attribute/1838/
> <https://discourse.wicg.io/t/inert-attribute/1838/>
> https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement

> <https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement>
>
>
> Summary
>
> The inert attribute allows 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.
>
>
>
> Blink component
>
> Blink>HTML

> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML>
>
>
> Search tags
>
> inert
> <https://chromestatus.com/features#tags:inert>, focus <https://chromestatus.com/features#tags:focus>, accessibility
> <https://chromestatus.com/features#tags:accessibility>, keyboard
> <https://chromestatus.com/features#tags:keyboard>, events
> <https://chromestatus.com/features#tags:events>, pointer
> <https://chromestatus.com/features#tags:pointer>

>
>
> TAG review
>
>
>
> TAG review status
>
> Pending
>
>
> Risks
>
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: Worth prototyping
> (https://mozilla.github.io/standards-positions/#inert-attr

> <https://mozilla.github.io/standards-positions/#inert-attr>)

>
> WebKit: No signal
>
> Web developers: Positive
> (https://www.a11yproject.com/announcements/2020-08-19-lets-support-inert/

> <https://www.a11yproject.com/announcements/2020-08-19-lets-support-inert/>)

>
>
> Is this feature fully tested
> by web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>
> Yes
>
>
> Tracking bug
>
> http://crbug.com/692360 <http://crbug.com/692360>

>
>
> Sample links
>
>
> https://wicg.github.io/inert/demo/
> <https://wicg.github.io/inert/demo/>
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5703266176335872
> <https://chromestatus.com/feature/5703266176335872>
>
>
> Links to previous Intent discussions
>
> Intent to
> prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/N--HhuYFJQI/m/bmwhhHDZCQAJ
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/N--HhuYFJQI/m/bmwhhHDZCQAJ>
>
>
> This intent message was generated by Chrome Platform

> Status <https://www.chromestatus.com/>.

>
> --
>
> 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+...@chromium.org.
>
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org?utm_medium=email&utm_source=footer>.

>
> --
> 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+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org?utm_medium=email&utm_source=footer>.

>
> --
> 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+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMQHGLxvY2aEr_sjzkJuP4PVwPe-Rbf190t8c93p38HPA1Ca7Q%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMQHGLxvY2aEr_sjzkJuP4PVwPe-Rbf190t8c93p38HPA1Ca7Q%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Emilio Cobos Álvarez]

On 4/15/21 14:07, Manuel Rego Casasnovas wrote:
> I'm also supportive of "inert", it's nice to see it coming to the browsers.
>
> I'm curious about the interop status, the feature hasn't shipped in
> Firefox yet so I'm not sure if this reflects the reality or not:
> https://wpt.fyi/results/inert?label=experimental&label=master&aligned
> Are Chromium and Firefox implementations interoperable?
>
> Apart from that, we haven't asked for signals to WebKit yet
> (https://bit.ly/blink-signals) unless I missed the mail.

wpt.fyi doesn't seem to be using the Firefox implementation of inert
because it's disabled by default. We enable it on automation and fail
some tests[1]. From a quick look:

* inert-node-is-uneditable.tentative.html fails because send_keys is
not implemented in Firefox, but if I do it manually, the test passes, so
it's not an issue.
* inert-node-is-unselectable.tentative.html is a false positive as
well (the inert node is in fact unselectable), but the test uses
document.execCommand("selectAll"), and that is not working as expected
in Firefox. I filed [2] for an expert on our editing code to weigh in,
but again inert seems to be behaving correctly.
* The iner-retargeting-*.html tests however are a known difference
between Firefox and Chrome. We don't want to implement special
hit-testing behavior for inert that is not exposed to CSS in other ways.
So if inert needs magic hit-testing behavior (and pointer-events: none
doesn't cut it for some reason) it should probably be a new
pointer-events value. This is tracked in [3] and there's some background
discussion in [4], and it doesn't seem there's consensus there...

More to the point, the main behavior difference is that `inert` in
Firefox is implemented in terms of CSS primitives, and does affect the
computed style of inert nodes (to have user-select: none,
pointer-events: none, cursor, etc [5]). I believe that's simpler
behavior to both implement and specify.

There also seems to be some other rather important spec issues that
haven't been resolved like [6], which I think we should get consensus on
before shipping.

-- Emilio

[1]:
https://searchfox.org/mozilla-central/search?q=inert&path=meta%2Finert%2F&case=false&regexp=false
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1705519
[3]: https://github.com/whatwg/html/issues/5650
[4]: https://github.com/mozilla/standards-positions/issues/174
[5]:
https://searchfox.org/mozilla-central/rev/5e70cd673a0ba0ad19b662c1cf656e0823781596/servo/components/style/style_adjuster.rs#195-205
[6]: https://github.com/w3c/html-aam/issues/295

[Alice Boxhall]

On Fri, Apr 16, 2021 at 5:39 AM Emilio Cobos Álvarez <emi...@mozilla.com> wrote:

On 4/15/21 14:07, Manuel Rego Casasnovas wrote:
> I'm also supportive of "inert", it's nice to see it coming to the browsers.
>
> I'm curious about the interop status, the feature hasn't shipped in
> Firefox yet so I'm not sure if this reflects the reality or not:
> https://wpt.fyi/results/inert?label=experimental&label=master&aligned
> Are Chromium and Firefox implementations interoperable?
>
> Apart from that, we haven't asked for signals to WebKit yet
> (https://bit.ly/blink-signals) unless I missed the mail.

No, I haven't sent it yet - partly hoping I could find some existing documentation of their support (sadly I haven't), and partly waiting for some more consensus on the issues raised here.

wpt.fyi doesn't seem to be using the Firefox implementation of inert
because it's disabled by default. We enable it on automation and fail
some tests[1]. From a quick look:

  * inert-node-is-uneditable.tentative.html fails because send_keys is
not implemented in Firefox, but if I do it manually, the test passes, so
it's not an issue.
  * inert-node-is-unselectable.tentative.html is a false positive as
well (the inert node is in fact unselectable), but the test uses
document.execCommand("selectAll"), and that is not working as expected
in Firefox. I filed [2] for an expert on our editing code to weigh in,
but again inert seems to be behaving correctly.
  * The iner-retargeting-*.html tests however are a known difference
between Firefox and Chrome. We don't want to implement special
hit-testing behavior for inert that is not exposed to CSS in other ways.
So if inert needs magic hit-testing behavior (and pointer-events: none
doesn't cut it for some reason) it should probably be a new
pointer-events value. This is tracked in [3] and there's some background
discussion in [4], and it doesn't seem there's consensus there...

More to the point, the main behavior difference is that `inert` in
Firefox is implemented in terms of CSS primitives, and does affect the
computed style of inert nodes (to have user-select: none,
pointer-events: none, cursor, etc [5]). I believe that's simpler
behavior to both implement and specify.

Ok, so to reiterate my reasoning for diverging from pointer-events: none behaviour (calling it "magic" just because it doesn't project to CSS is unwarranted in my opinion), and why I don't think that's a problem:

• Firstly, I think that pointer-events: none in HTML is a mis-feature. That might be something I just have to get over, since it's now deeply entangled with all of our hit-testing logic, but my reasons for feeling this way are:
• It can create a bad user experience if opaque content with pointer-events: none is positioned over clickable content, since you can now click content you can't see.
• The naming doesn't make sense when (as in HTML, but not in SVG where it originated) the only options are auto or none. It makes it appear as though "none" refers to the events, rather than the box, and sets an expectation that it's going to swallow pointer events, rather than make the element "transparent" to events (which makes sense if and only if the element is visually transparent, which was the intent of the feature in SVG as far as I can tell).
• Secondly, the value of inert is largely that it makes content non-interactive for all modalities, rather than just pointers. This is a deliberate choice, because vast amounts of content is built exclusively considering the needs of users who used pointer-based devices, creating poor experiences for users of other modalities. I would like to encourage authors to use inert instead of pointer-events: none (or pointer-events: inert if/when such a thing eventuates) as much as possible.
• Thirdly, I haven't seen an urgent use case for authors needing a way to detect when (inert) content matches pointer-events: none. That doesn't mean that it doesn't exist, but that I don't see any reason to consider not having it to be a blocking issue. Even if it does ship later, the risk that code could depend on inert content not matching pointer-events: none seems non-existent.

All of that said: it does seem that some recent refactoring has subtly broken the event retargeting code in ways I hadn't tested for, so I'm planning to admit defeat and revert to the original (pointer-events: none-like) behaviour, both in the spec and in the code. If someone would like to make further changes such that it matches pointer-events: none I'm not going to stand in their way, as long as my reasoning above is understood.  

There also seems to be some other rather important spec issues that
haven't been resolved like [6], which I think we should get consensus on
before shipping.

The spec actually doesn't state an opinion (and in fact it has no way to do so) on whether inert nodes should be exposed to assistive technology (AT) APIs. We can and frequently do make changes to how content is exposed to AT to improve the user experience.

[Emilio Cobos Álvarez]

On 4/20/21 06:47, Alice Boxhall wrote:
>
>
> On Fri, Apr 16, 2021 at 5:39 AM Emilio Cobos Álvarez <emi...@mozilla.com
> <mailto:emi...@mozilla.com>> wrote:
>
> On 4/15/21 14:07, Manuel Rego Casasnovas wrote:
> > I'm also supportive of "inert", it's nice to see it coming to the
> browsers.
> >
> > I'm curious about the interop status, the feature hasn't shipped in
> > Firefox yet so I'm not sure if this reflects the reality or not:
> >

> https://wpt.fyi/results/inert?label=experimental&label=master&aligned <https://wpt.fyi/results/inert?label=experimental&label=master&aligned>

> > Are Chromium and Firefox implementations interoperable?
> >
> > Apart from that, we haven't asked for signals to WebKit yet

> > (https://bit.ly/blink-signals <https://bit.ly/blink-signals>)

> * Firstly, I think that pointer-events: none in HTML is a mis-feature.

> That might be something I just have to get over, since it's now
> deeply entangled with all of our hit-testing logic, but my reasons
> for feeling this way are:

> o It can create a bad user experience if opaque content with

> pointer-events: none is positioned over clickable content, since
> you can now click content you can't see.

> o The naming doesn't make sense when (as in HTML, but not in SVG

> where it originated) the only options are auto or none. It makes

> it appear as though "none" refers to the /events/, rather than

> the box, and sets an expectation that it's going to swallow
> pointer events, rather than make the element "transparent" to

> events (which makes sense if and only if the element /is/

> visually transparent, which was the intent of the feature in SVG
> as far as I can tell).

So, I disagree that stuff affecting hit-testing doesn't belong to CSS
fwiw, but I agree with the other comments. There are existing issues in
the CSSWG repo to add more values to pointer-events that do something
closer to what you want to do for inert, I think.

> * Secondly, the value of inert is largely that it makes content
> non-interactive for /all/ modalities, rather than just pointers.

> This is a deliberate choice, because vast amounts of content is
> built exclusively considering the needs of users who used
> pointer-based devices, creating poor experiences for users of other

> modalities. I would like to encourage authors to use inert/instead
> of/ pointer-events: none (or pointer-events: inertif/when such a

> thing eventuates) as much as possible.

Sure, this I totally agree with! But that doesn't mean that inert
shouldn't be implemented in terms of other pre-existing primitives like
user-select, pointer-events, etc when those are already available, IMO.

> * Thirdly, I haven't seen an urgent use case for authors needing a way

> to detect when (inert) content matches pointer-events: none. That
> doesn't mean that it doesn't exist, but that I don't see any reason
> to consider not having it to be a blocking issue. Even if it does
> ship later, the risk that code could depend on inert content

> /not/ matching pointer-events: none seems non-existent.

I think that seems fair. To be clear that we can't think of an use case
for it doesn't mean that that doesn't exist, but I agree it's probably
not a blocking issue.

We can probably define the precise hit-testing behavior we want
somewhere like in this CSSWG issue[1], and then using it from inert?

I _think_ you're part of the working group so should be able to add that
to the agenda, but if not I or some of the Chromium rendering folks can
probably do it, just let me (or them) know :)

> All of that said: it does seem that some recent refactoring has subtly
> broken the event retargeting code in ways I hadn't tested for, so I'm
> planning to admit defeat and revert to the original (pointer-events:
> none-like) behaviour, both in the spec and in the code. If someone would
> like to make further changes such that it matches pointer-events: none
> I'm not going to stand in their way, as long as my reasoning above is
> understood.

Alright, that sounds great. I think it makes sense for inert to change
computed styles (both from an authoring and implementation point of
view), but I agree it's probably not a huge deal, as long as the
behavior matches what authors can accomplish via CSS and other means.

I think it'd be ideal to not ship with this difference, but
in any case I agree the risk for interop issues is relatively low,
specially if the hit-testing behavior will actually match across browsers.

> There also seems to be some other rather important spec issues that
> haven't been resolved like [6], which I think we should get
> consensus on
> before shipping.
>
>
> The spec actually doesn't state an opinion (and in fact it has no way to
> do so) on whether inert nodes should be exposed to assistive technology
> (AT) APIs. We can and frequently do make changes to how content is
> exposed to AT to improve the user experience.

I guess I'm not so familiar with how a11y features are usually
standardized, but given that behavior is not directly web-exposed I
guess that might be fair? I think ideally we'd all agree on how to
expose stuff to ATs though...

[1]: https://github.com/w3c/csswg-drafts/issues/4499

-- Emilio

>
>
>   -- Emilio
>
> [1]:
> https://searchfox.org/mozilla-central/search?q=inert&path=meta%2Finert%2F&case=false&regexp=false
> <https://searchfox.org/mozilla-central/search?q=inert&path=meta%2Finert%2F&case=false&regexp=false>
> [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1705519
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1705519>
> [3]: https://github.com/whatwg/html/issues/5650
> <https://github.com/whatwg/html/issues/5650>
> [4]: https://github.com/mozilla/standards-positions/issues/174
> <https://github.com/mozilla/standards-positions/issues/174>
> [5]:
> https://searchfox.org/mozilla-central/rev/5e70cd673a0ba0ad19b662c1cf656e0823781596/servo/components/style/style_adjuster.rs#195-205
> <https://searchfox.org/mozilla-central/rev/5e70cd673a0ba0ad19b662c1cf656e0823781596/servo/components/style/style_adjuster.rs#195-205>
> [6]: https://github.com/w3c/html-aam/issues/295
> <https://github.com/w3c/html-aam/issues/295>
>
> >
> > Cheers,
> >    Rego
> >
> > On 13/04/2021 08:46, Alice Boxhall wrote:
> >> Sorry for putting off replying to this, I've been trying to weigh up
> >> what I actually think about it all.
> >>
> >> On Fri, Apr 9, 2021 at 4:13 AM Mike West <mk...@chromium.org
> <mailto:mk...@chromium.org>

> >> <mailto:mk...@chromium.org <mailto:mk...@chromium.org>>> wrote:
> >>
> >>      I also think this looks quite reasonable, and I think it's
> a good
> >>      addition to the platform. That said, I think Yoav's
> questions about
> >>      the details and Mozilla's approach are good ones. Alice, how do
> >>      you think we should handle them?
> >>
> >>      -mike
> >>
> >>
> >>      On Thu, Apr 8, 2021 at 12:45 AM 'Alex Russell' via blink-dev
> >>      <blin...@chromium.org <mailto:blin...@chromium.org>

> <mailto:yoav...@chromium.org>> wrote:
> >>
> >>
> >>
> >>                  On Tuesday, March 30, 2021 at 5:58:24 AM UTC+2
> A Boxhall
> >>                  wrote:
> >>
> >>
> >>                              Contact emails
> >>

> >> abox...@chromium.org <mailto:abox...@chromium.org>

> blink-dev+...@chromium.org <mailto:blink-dev%2B...@chromium.org>.

> >>
> >>                  To view this discussion on the web visit
> >>

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org>
> >>
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org?utm_medium=email&utm_source=footer

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org?utm_medium=email&utm_source=footer>>.
> >>
> >>          --
> >>          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+...@chromium.org

> <mailto:blink-dev%2Bunsu...@chromium.org>
> >>          <mailto:blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>>.

> >>          To view this discussion on the web visit
> >>
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org>
> >>

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org?utm_medium=email&utm_source=footer

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org?utm_medium=email&utm_source=footer>>.
> >>
> >> --
> >> 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+...@chromium.org

> <mailto:blink-dev%2Bunsu...@chromium.org>
> >> <mailto:blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>>.

> >> To view this discussion on the web visit
> >>
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMQHGLxvY2aEr_sjzkJuP4PVwPe-Rbf190t8c93p38HPA1Ca7Q%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMQHGLxvY2aEr_sjzkJuP4PVwPe-Rbf190t8c93p38HPA1Ca7Q%40mail.gmail.com>
> >>

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMQHGLxvY2aEr_sjzkJuP4PVwPe-Rbf190t8c93p38HPA1Ca7Q%40mail.gmail.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMQHGLxvY2aEr_sjzkJuP4PVwPe-Rbf190t8c93p38HPA1Ca7Q%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
> >
>

[Alice Boxhall]

+Dominic Mazzoni who will be following up on this while I'm out on sabbatical.

I spent the last few days trying to revert to using pointer-events: none and realised that there are even more issues with it than I had remembered; specifically that it excludes the element from `getElement[s]FromPoint()`, which also means it's difficult to inspect the element.

(To experience this, go to http://wpt.live/inert/inert-retargeting.tentative.html and try to inspect the "foreground" button.)

I realise now that it's also not broken the way I thought it was.

So I think I would be happier shipping what is currently specced and implemented than trying to ship the pointer-events: none behaviour which I think will be too frustrating for both authors and developers to use.

>   * Secondly, the value of inert is largely that it makes content
>     non-interactive for /all/ modalities, rather than just pointers.
>     This is a deliberate choice, because vast amounts of content is
>     built exclusively considering the needs of users who used
>     pointer-based devices, creating poor experiences for users of other
>     modalities. I would like to encourage authors to use inert/instead
>     of/ pointer-events: none (or pointer-events: inertif/when such a
>     thing eventuates) as much as possible.

Sure, this I totally agree with! But that doesn't mean that inert
shouldn't be implemented in terms of other pre-existing primitives like
user-select, pointer-events, etc when those are already available, IMO.

I'm not against using user-select, but I also don't think that's a reason to block shipping.

>   * Thirdly, I haven't seen an urgent use case for authors needing a way
>     to detect when (inert) content matches pointer-events: none. That
>     doesn't mean that it doesn't exist, but that I don't see any reason
>     to consider not having it to be a blocking issue. Even if it does
>     ship later, the risk that code could depend on inert content
>     /not/ matching pointer-events: none seems non-existent.

I think that seems fair. To be clear that we can't think of an use case
for it doesn't mean that that doesn't exist, but I agree it's probably
not a blocking issue.

We can probably define the precise hit-testing behavior we want
somewhere like in this CSSWG issue[1], and then using it from inert?

I can't see why we'd block on that when there isn't a clear user need for it which isn't also a use case for inert (and where inert would be better suited).

We definitely want things to be as consistent as possible, but we don't block on consensus.

[Emilio Cobos Álvarez]

On 4/22/21 09:52, Alice Boxhall wrote:
> +Dominic Mazzoni <mailto:dmaz...@chromium.org> who will be following up

> on this while I'm out on sabbatical.
>
> On Tue, Apr 20, 2021 at 9:21 PM Emilio Cobos Álvarez <emi...@mozilla.com
> <mailto:emi...@mozilla.com>> wrote:
>
>
>
> On 4/20/21 06:47, Alice Boxhall wrote:
> >
> >
> > On Fri, Apr 16, 2021 at 5:39 AM Emilio Cobos Álvarez
> <emi...@mozilla.com <mailto:emi...@mozilla.com>

> > <mailto:emi...@mozilla.com <mailto:emi...@mozilla.com>>> wrote:
> >
> >     On 4/15/21 14:07, Manuel Rego Casasnovas wrote:
> >      > I'm also supportive of "inert", it's nice to see it coming
> to the
> >     browsers.
> >      >
> >      > I'm curious about the interop status, the feature hasn't
> shipped in
> >      > Firefox yet so I'm not sure if this reflects the reality
> or not:
> >      >
> >
> https://wpt.fyi/results/inert?label=experimental&label=master&aligned <https://wpt.fyi/results/inert?label=experimental&label=master&aligned>
> <https://wpt.fyi/results/inert?label=experimental&label=master&aligned
> <https://wpt.fyi/results/inert?label=experimental&label=master&aligned>>
> >      > Are Chromium and Firefox implementations interoperable?
> >      >
> >      > Apart from that, we haven't asked for signals to WebKit yet
> >      > (https://bit.ly/blink-signals

> <https://bit.ly/blink-signals> <https://bit.ly/blink-signals

Well, getElement(s)FromPoint is intended to hit-test the page. If the
element is not hit-testable, it should not be in the results of
getElementsFromPoint(). I disagree that getElementsFromPoint() should
return inert elements, that seems broken.

-- Emilio

> >     <mailto:yoav...@chromium.org <mailto:yoav...@chromium.org>>>

> wrote:
> >      >>
> >      >>
> >      >>
> >      >>                  On Tuesday, March 30, 2021 at 5:58:24 AM
> UTC+2
> >     A Boxhall
> >      >>                  wrote:
> >      >>
> >      >>
> >      >>                              Contact emails
> >      >>
> >      >> abox...@chromium.org <mailto:abox...@chromium.org>

> <mailto:abox...@chromium.org <mailto:abox...@chromium.org>>

>  <https://www.a11yproject.com/announcements/2020-08-19-lets-support-inert/ <https://www.a11yproject.com/announcements/2020-08-19-lets-support-inert/>>>)

> <mailto:blink-dev%2B...@chromium.org
> <mailto:blink-dev%252B...@chromium.org>>.

> >      >>
> >      >>                  To view this discussion on the web visit
> >      >>
> >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org>
> >
>  <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org>>
> >      >>
> >
>  <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org?utm_medium=email&utm_source=footer>
> >
>  <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa08991b-a16e-45de-ac56-16b6680b7889n%40chromium.org?utm_medium=email&utm_source=footer>>>.
> >      >>
> >      >>          --
> >      >>          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+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>

> >     <mailto:blink-dev%2Bunsu...@chromium.org
> <mailto:blink-dev%252Buns...@chromium.org>>
> >      >>          <mailto:blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>
> >     <mailto:blink-dev%2Bunsu...@chromium.org
> <mailto:blink-dev%252Buns...@chromium.org>>>.

> >      >>          To view this discussion on the web visit
> >      >>
> >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org>
> >
>  <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org>>
> >      >>
> >
>  <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org?utm_medium=email&utm_source=footer>
> >
>  <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3e2030-3103-48e2-b048-005bfa98462cn%40chromium.org?utm_medium=email&utm_source=footer>>>.
> >      >>
> >      >> --
> >      >> 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+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>

> >     <mailto:blink-dev%2Bunsu...@chromium.org
> <mailto:blink-dev%252Buns...@chromium.org>>
> >      >> <mailto:blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>
> >     <mailto:blink-dev%2Bunsu...@chromium.org
> <mailto:blink-dev%252Buns...@chromium.org>>>.

[obr...@igalia.com]

I would like to resurrect this intent to ship. Or would it be better to send a new one instead?

Anyways, the current state is that:

• The inert attribute has been added into the HTML spec: https://html.spec.whatwg.org/multipage/interaction.html#the-inert-attribute
• WebKit shipped it already: https://bugs.webkit.org/show_bug.cgi?id=235668
• Firefox has implemented it behind a flag (html5.inert.enabled): https://bugzilla.mozilla.org/show_bug.cgi?id=1655722
• I have refactored Blink's implementation in terms of CSS primitives per CSSWG resolution, aligning with Firefox and WebKit, which should imply more interoperability.
• The effects of inertness are basically:
  • 'pointer-events: none' at used-value time
    
  • 'user-select: none' at used-value time
  • '-webkit-user-modify: read-only' at used-value time
  • No focusability
  • Ignored and invisible for a11y
• WPT:
  • https://wpt.fyi/results/inert
  • https://wpt.fyi/results/html/semantics/interactive-elements/the-dialog-element?q=inert

-- Oriol Brufau

El dia dijous, 22 d’abril de 2021 a les 12:29:08 UTC+2, Emilio Cobos Alvarez va escriure:

[Chris Harrelson]

Re-using the thread makes sense to me, but let's re-start the LGTMs.

LGTM1 from me. Really glad that there is a consensus spec and that all browsers are shipping together!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eca4575a-42ad-40a4-8698-311e43d55c4en%40chromium.org.

[Chris Harrelson]

Oriol, I've made you an owner of the Chromestatus entry. Could you please update it, fill in all fields to the new status, and mark it as review for intent-to-ship?

Right now I see a few things that need update
* Description of feature (maybe?)

* Milestone when it'll ship

* Debuggability analysis

[Chris Harrelson]

On Thu, Mar 10, 2022 at 9:30 AM Chris Harrelson <chri...@chromium.org> wrote:

Oriol, I've made you an owner of the Chromestatus entry. Could you please update it, fill in all fields to the new status, and mark it as review for intent-to-ship?

Right now I see a few things that need update
* Description of feature (maybe?)

* Milestone when it'll ship

* Debuggability analysis

* Shipping status in other engines

[Oriol Brufau]

Done. I set 101 as the milestone since we are very close to the branch point for 100.
I didn't find "review for intent-to-ship", chose "prepare to ship".

-- Oriol Brufau

El 10/3/22 a les 18:30, Chris Harrelson ha escrit:

[TAMURA, Kent]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0a5fdb6e-2ba2-0f51-29c8-ea596b758459%40igalia.com.

--

TAMURA Kent
Software Engineer, Google