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-g-p7obbp7OaVxc5m7z7nUh4d%2B95-3DJab1_aqPnktBQ%40mail.gmail.com.
