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 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-qSsk%3DsQKCr2ie5pZ%3DE3Obyg8T4KM8vDDVuRWLDrSgyg%40mail.gmail.com.
