On Thu, Mar 10, 2022 at 9:30 AM Chris Harrelson <[email protected]> wrote:
> Oriol, I've made you an owner of the Chromestatus entry > <https://chromestatus.com/feature/5703266176335872>. 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 > > On Thu, Mar 10, 2022 at 9:26 AM Chris Harrelson <[email protected]> > wrote: > >> 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! >> >> >> >> On Thu, Mar 10, 2022 at 9:22 AM [email protected] <[email protected]> >> wrote: >> >>> 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: >>> >>>> >>>> >>>> On 4/22/21 09:52, Alice Boxhall wrote: >>>> > +Dominic Mazzoni <mailto:[email protected]> 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 < >>>> [email protected] >>>> > <mailto:[email protected]>> wrote: >>>> > >>>> > >>>> > >>>> > On 4/20/21 06:47, Alice Boxhall wrote: >>>> > > >>>> > > >>>> > > On Fri, Apr 16, 2021 at 5:39 AM Emilio Cobos Álvarez >>>> > <[email protected] <mailto:[email protected]> >>>> > > <mailto:[email protected] <mailto:[email protected]>>> 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 >>>> > <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: >>>> > > 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. >>>> > >>>> > >>>> > 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. >>>> >>>> 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 >>>> >>>> > (To experience this, go to >>>> > http://wpt.live/inert/inert-retargeting.tentative.html >>>> > <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). >>>> > >>>> > 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... >>>> > >>>> > >>>> > We definitely want things to be as consistent as possible, but we >>>> don't >>>> > block on consensus. >>>> > >>>> > >>>> > [1]: https://github.com/w3c/csswg-drafts/issues/4499 >>>> > <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®exp=false >>>> > < >>>> https://searchfox.org/mozilla-central/search?q=inert&path=meta%2Finert%2F&case=false®exp=false> >>>> >>>> > > >>>> > < >>>> https://searchfox.org/mozilla-central/search?q=inert&path=meta%2Finert%2F&case=false®exp=false >>>> < >>>> https://searchfox.org/mozilla-central/search?q=inert&path=meta%2Finert%2F&case=false®exp=false>> >>>> >>>> > > [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1705519 >>>> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1705519> >>>> > > <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> >>>> > > <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> >>>> > > <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> >>>> >>>> > > >>>> > < >>>> 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> >>>> > > <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 >>>> > <[email protected] <mailto:[email protected]> >>>> > > <mailto:[email protected] <mailto:[email protected]>> >>>> > > >> <mailto:[email protected] <mailto:[email protected]> >>>> > <mailto:[email protected] <mailto:[email protected]>>>> 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 >>>> > > >> <[email protected] >>>> > <mailto:[email protected]> <mailto:[email protected] >>>> > <mailto:[email protected]>> >>>> > > <mailto:[email protected] >>>> > <mailto:[email protected]> <mailto:[email protected] >>>> > <mailto:[email protected]>>>> 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 >>>> > > >> <[email protected] >>>> > <mailto:[email protected]> >>>> > > <mailto:[email protected] <mailto:[email protected]>>> >>>> > wrote: >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> On Tuesday, March 30, 2021 at 5:58:24 AM >>>> > UTC+2 >>>> > > A Boxhall >>>> > > >> wrote: >>>> > > >> >>>> > > >> >>>> > > >> Contact emails >>>> > > >> >>>> > > >> [email protected] <mailto:[email protected]> >>>> > <mailto:[email protected] <mailto:[email protected]>> >>>> > > >> >>>> > > >> >>>> > > >> Explainer >>>> > > >> >>>> > > >> >>>> > > >> https://github.com/WICG/inert/blob/main/explainer.md >>>> > <https://github.com/WICG/inert/blob/main/explainer.md> >>>> > > <https://github.com/WICG/inert/blob/main/explainer.md >>>> > <https://github.com/WICG/inert/blob/main/explainer.md>> >>>> > > >> >>>> > > <https://github.com/WICG/inert/blob/main/explainer.md >>>> > <https://github.com/WICG/inert/blob/main/explainer.md> >>>> > > <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> >>>> > > <https://github.com/whatwg/html/pull/4288 >>>> > <https://github.com/whatwg/html/pull/4288>> >>>> > > >> >>>> > <https://github.com/whatwg/html/pull/4288 >>>> > <https://github.com/whatwg/html/pull/4288> >>>> > > <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 >>>> > <https://github.com/whatwg/html/pull/4288#issuecomment-684009827> >>>> > > >>>> > <https://github.com/whatwg/html/pull/4288#issuecomment-684009827 >>>> > <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://github.com/WICG/inert#tldr >>>> > <https://github.com/WICG/inert#tldr>> >>>> > > >> <https://github.com/WICG/inert#tldr >>>> > <https://github.com/WICG/inert#tldr> >>>> > > <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://discourse.wicg.io/t/inert-attribute/1838/ >>>> > <https://discourse.wicg.io/t/inert-attribute/1838/>> >>>> > > >> >>>> > > <https://discourse.wicg.io/t/inert-attribute/1838/ >>>> > <https://discourse.wicg.io/t/inert-attribute/1838/> >>>> > > <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> >>>> > > <https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement >>>> > <https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement>> >>>> > > >> >>>> > > <https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement >>>> > <https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement> >>>> > > <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 >>>> < >>>> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML> >>>> >>>> > > >>>> > < >>>> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML >>>> < >>>> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML>>> >>>> >>>> > > >> >>>> > > >> >>>> > > >> Search tags >>>> > > >> >>>> > > >> inert >>>> > > >> >>>> > > <https://chromestatus.com/features#tags:inert >>>> > <https://chromestatus.com/features#tags:inert> >>>> > > <https://chromestatus.com/features#tags:inert >>>> > <https://chromestatus.com/features#tags:inert>>>, focus >>>> > > <https://chromestatus.com/features#tags:focus >>>> > <https://chromestatus.com/features#tags:focus> >>>> > > <https://chromestatus.com/features#tags:focus >>>> > <https://chromestatus.com/features#tags:focus>>>, accessibility >>>> > > >> >>>> > > <https://chromestatus.com/features#tags:accessibility >>>> > <https://chromestatus.com/features#tags:accessibility> >>>> > > <https://chromestatus.com/features#tags:accessibility >>>> > <https://chromestatus.com/features#tags:accessibility>>>, keyboard >>>> > > >> >>>> > > <https://chromestatus.com/features#tags:keyboard >>>> > <https://chromestatus.com/features#tags:keyboard> >>>> > > <https://chromestatus.com/features#tags:keyboard >>>> > <https://chromestatus.com/features#tags:keyboard>>>, events >>>> > > >> >>>> > > <https://chromestatus.com/features#tags:events >>>> > <https://chromestatus.com/features#tags:events> >>>> > > <https://chromestatus.com/features#tags:events >>>> > <https://chromestatus.com/features#tags:events>>>, pointer >>>> > > >> >>>> > > <https://chromestatus.com/features#tags:pointer >>>> > <https://chromestatus.com/features#tags:pointer> >>>> > > <https://chromestatus.com/features#tags: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> >>>> > > <https://mozilla.github.io/standards-positions/#inert-attr >>>> > <https://mozilla.github.io/standards-positions/#inert-attr>> >>>> > > >> >>>> > > <https://mozilla.github.io/standards-positions/#inert-attr >>>> > <https://mozilla.github.io/standards-positions/#inert-attr> >>>> > > <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/> >>>> >>>> > > >>>> > < >>>> https://www.a11yproject.com/announcements/2020-08-19-lets-support-inert/ >>>> < >>>> https://www.a11yproject.com/announcements/2020-08-19-lets-support-inert/>> >>>> >>>> > > >> >>>> > > >>>> > < >>>> https://www.a11yproject.com/announcements/2020-08-19-lets-support-inert/ >>>> < >>>> https://www.a11yproject.com/announcements/2020-08-19-lets-support-inert/> >>>> >>>> > > >>>> > < >>>> 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 >>>> < >>>> https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>> >>>> > > >>>> > < >>>> https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md >>>> < >>>> https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>>>? >>>> >>>> > > >> >>>> > > >> Yes >>>> > > >> >>>> > > >> >>>> > > >> Tracking bug >>>> > > >> >>>> > > >> http://crbug.com/692360 <http://crbug.com/692360> >>>> > <http://crbug.com/692360 <http://crbug.com/692360>> >>>> > > <http://crbug.com/692360 <http://crbug.com/692360> >>>> > <http://crbug.com/692360 <http://crbug.com/692360>>> >>>> > > >> >>>> > > >> >>>> > > >> Sample links >>>> > > >> >>>> > > >> >>>> > > >> https://wicg.github.io/inert/demo/ >>>> > <https://wicg.github.io/inert/demo/> >>>> > > <https://wicg.github.io/inert/demo/ >>>> > <https://wicg.github.io/inert/demo/>> >>>> > > >> <https://wicg.github.io/inert/demo/ >>>> > <https://wicg.github.io/inert/demo/> >>>> > > <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> >>>> > > <https://chromestatus.com/feature/5703266176335872 >>>> > <https://chromestatus.com/feature/5703266176335872>> >>>> > > >> >>>> > > <https://chromestatus.com/feature/5703266176335872 >>>> > <https://chromestatus.com/feature/5703266176335872> >>>> > > <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> >>>> >>>> > > >>>> > < >>>> 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>> >>>> >>>> > > >> >>>> > > >>>> > < >>>> 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> >>>> >>>> > > >>>> > < >>>> 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/ <https://www.chromestatus.com/> >>>> > > <https://www.chromestatus.com/ <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 >>>> > > [email protected] <mailto:blink-dev%[email protected]> >>>> > <mailto:blink-dev%[email protected] >>>> > <mailto:blink-dev%[email protected]>>. >>>> > > >> >>>> > > >> 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 >>>> > [email protected] >>>> > <mailto:blink-dev%[email protected]> >>>> > > <mailto:blink-dev%[email protected] >>>> > <mailto:blink-dev%[email protected]>> >>>> > > >> <mailto:[email protected] >>>> > <mailto:blink-dev%[email protected]> >>>> > > <mailto:blink-dev%[email protected] >>>> > <mailto:blink-dev%[email protected]>>>. >>>> > > >> 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 [email protected] >>>> > <mailto:blink-dev%[email protected]> >>>> > > <mailto:blink-dev%[email protected] >>>> > <mailto:blink-dev%[email protected]>> >>>> > > >> <mailto:[email protected] >>>> > <mailto:blink-dev%[email protected]> >>>> > > <mailto:blink-dev%[email protected] >>>> > <mailto:blink-dev%[email protected]>>>. >>>> > > >> 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 >>>> < >>>> 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> >>>> >>>> > > >>>> > < >>>> 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>>>. >>>> >>>> > > > >>>> > > >>>> > >>>> >>> -- >>> 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 [email protected]. >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eca4575a-42ad-40a4-8698-311e43d55c4en%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-me87eGYeNp4cjFy8jGxHTQb8NENzqrvA2H50kCHQmxg%40mail.gmail.com.
