Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re add inert #4288

Closed
wants to merge 11 commits into from
Closed

Re add inert #4288

wants to merge 11 commits into from

Conversation

alice
Copy link

@alice alice commented Jan 14, 2019

Re-adds the inert attribute, and clarifies mouse pointer and event behaviour for the inert concept.

See https://github.com/WICG/inert/blob/master/explainer.md for justification.

Taken over from #1474.


馃挜 Error: Wattsi server error 馃挜

PR Preview failed to build. (Last tried on Mar 31, 2021, 2:47 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

馃毃 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.

馃敆 Related URL

<html>
<head><title>524 Origin Time-out</title></head>
<body bgcolor="white">
<center><h1>524 Origin Time-out</h1></center>
<hr><center>cloudflare-nginx</center>
</body>
</html>

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

@alice
Copy link
Author

alice commented Jan 14, 2019

Replying to #1474 (comment)


The new text doesn't seem right though. It has the following normative consequence:

document.body.addEventListener("foo", () => console.log("foo event fired"));
document.body.inert = true;

document.body.dispatchEvent(new Event("foo")); // doesn't log anything

That actually seems right to me. @robdodson had the same reaction when I checked with him.

(Edited to add) Specifically, I think it would be more confusing for authors if some events worked, sometimes, than if events simply didn't work.

However, I just realised there's still an issue with event delegation as written, so some edits to UI events are still needed...

In addition it's a pretty heavy monkeypatch to the event dispatch algorithm, although I guess that was already true for the previous patch in some ways.

Agreed.

It seems like you're going for (3) in #1474 (comment), right? My stab at some text for that would be "User interactions which would otherwise cause events to be targeted at an inert element must instead do nothing". Not sure that's great either...

More like (2) (which was poorly worded) - the event fires, but nothing happens at the targeting phase. Capture/bubble work as normal.

@alice
Copy link
Author

alice commented Jan 14, 2019

However, I just realised there's still an issue with event delegation as written, so some edits to UI events are still needed...

Actually, I think we can avoid that. Will make some edits and ping this PR when ready.

@domenic
Copy link
Member

domenic commented Jan 14, 2019

That actually seems right to me. @robdodson had the same reaction when I checked with him.

Hmm. I don't think this is OK. We can't have a high-level, UI/UX HTML-level content attribute interfere with foundational EventTarget-level technologies like dispatching custom events. We should only be changing UI interaction behavior, not general event functionality.

@alice
Copy link
Author

alice commented Jan 14, 2019

Ok, I'm convinced. Will look at UI Events.

@alice
Copy link
Author

alice commented Jan 15, 2019

Hm - so I had a chat to Gary K and apparently there's no easy place for it to hook in right now.

Some options:

  • Make a vague reference to UI Events, details to be filled in in that spec.
  • Spec what is currently implemented in Chrome, which is:
    • Element cannot be focused
    • Element cannot be selected
    • Element is not visible to hit testing - this seems quite difficult to actually spec, since I can't find where hit testing is defined.

@annevk
Copy link
Member

annevk commented Jan 15, 2019

Element is not visible to hit testing

Hit testing is indeed not defined, but can be observed through various means (e.g., elementFromPoint()). Perhaps this can be defined in terms of the pointer-events CSS property? It seems if it cannot be hit tested or focused, you cannot get to it with UI Events either, right? So that would automatically be solved.

Focusing is defined in HTML, so could be patched there. Selection is in https://w3c.github.io/selection-api/.

@domenic
Copy link
Member

domenic commented Jan 15, 2019

I don't think there's a great solution here in terms of creating a perfect spec, at least until w3c/uievents#200 is done. So we just need to focus practically on writing a good enough spec to get interop.

For that route, I would:

  • Hook into focus. Oh, this is already done in the spec today, yay! :)
  • Have a vague summary statement (like "the user agent must act as if the node was absent for the purposes of targeting user interaction events" but more accurate). Then help out by adding more details corresponding to what Chrome intends to implement. Some examples:
    • "The element is ignored for the purposes of "hit testing" (a not-yet-defined part of the web platform, related to the 'pointer-events' CSS property)"
    • Explicitly list the events that will never fire on the element.
    • Expand the current note about "may prevent the user from selecting text in that node" to also cover http://localhost:8080/#dom-textarea/input-setselectionrange (what does Chrome do for that method on inert elements?)

As for defining in terms of pointer-events, it appears that's not specced anywhere precisely because properly speccing it would require defining hit testing: https://wiki.csswg.org/spec/css4-ui#pointer-events :)

@annevk
Copy link
Member

annevk commented Jan 16, 2019

I'm not sure I understand why not. It's commonly understood that most UI Events always goes through hit testing (keyboard stuff relies on focus). pointer-events affects hit testing and has a none value. So if we specified that user agents need to act as if pointer-events is none for the relevant element, that would be reasonably well-defined and even future proof (i.e., need no adjusting when UI Events is properly specified or even when hit testing is properly specified).

@domenic
Copy link
Member

domenic commented Jan 16, 2019

@alice, can you comment on how Chrome's implementation of inert="" (or, alternately, the ideal implementation of inert="") maps onto Chrome's pointer-events implementation?

@alice
Copy link
Author

alice commented Jan 16, 2019

When checking whether a layout object/paint fragment is visible to hit testing, the associated Node is queried for both pointer events style and inertness.
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/layout/layout_object.h?type=cs&sq=package:chromium&g=0&l=1709

pointer-events explicitly allows the "transparent to click events" behaviour, which I find frankly alarming if not paired with at least partial transparency.

@alice
Copy link
Author

alice commented Jan 17, 2019

I spoke to Tab about this, and he explained what pointer-events: none actually means, i.e. "no part (none) of the shape defined by this thing is visible to pointer events". This to me makes it seem like less of a good fit for inert, which Tab described as more "absorbing events", which I liked, and proposed that I could propose some kind of pointer-events-behavio[u]r property to go along with inert.

So, I think that's kind of back to the drawing board a little bit. I definitely want the "absorb events" behaviour rather than the "transparent to hit testing" behaviour. Will keep thinking about how that might be written.

@domenic
Copy link
Member

domenic commented Jan 17, 2019

Sounds like the difference between the two will make for some good web platform tests! But yeah, writing up bespoke text that's clear enough to get interoperability for now, and later maybe grounding in a new CSS primitive, makes sense to me.

@alice
Copy link
Author

alice commented Mar 18, 2019

I added a blacklist of events not to be fired, and a comment about setSelectionRange().

I decided the hit testing piece is probably unnecessary - for example, getElementsFromPoint() should probably still work for things like contrast ratio testing (used to figure out background colour).

@alice
Copy link
Author

alice commented Mar 19, 2019

On further thought, decided I did need to say something about hit testing - these elements will still show up for hit testing in general, but events which would be targeted by hit testing should be targeted at ancestors instead.

The wording is a little convoluted - my intention is to avoid the "click through to an unrelated element" scenario which pointer-events: none allows, and instead require that the event target be an ancestor, but still an ancestor which would be in elementsFromPoint.

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this!

source Outdated

<ul>
<li>
<p>the user agent must not fire any of the following events on the node:</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. When would this safelist apply? Does this only apply when the user agent is responsible for dispatching these events? Or would this also happen for synthetic events?
  2. It seems highly likely this safelist will go out-of-date when new events get added. What about pointer events for instance? I'd be much more comfortable with this kind of setup if there were some intrinsic properties on the event object that indicate whether to filter it as such.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. In either case.
  2. There's not really any good option here; I agree the blacklist will need to be kept up to date until we have some kind of way of referring to user input events as a class.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So then it should probably be defined as a modification of https://dom.spec.whatwg.org/#concept-event-dispatch?

Are pointer events in or out? That wasn't clear from your answer.

Does it apply regardless of what class the event implements? E.g., click with CustomEvent gets filtered?

A lot of that seems rather different from existing setups, so I'm not entirely convinced it's the design we want to use.

(FWIW, we try to avoid using "whitelist" and "blacklist", preferring "safelist" and "blocklist": https://whatwg.org/style-guide#tone.)

Copy link
Author

@alice alice Apr 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understood re language (and thanks for the pointer) - I meant more that it's a blocklist rather than a safelist, since these events will not fire.

I do think this is the design we want in terms of behaviour - in lay terms, we want any event which is or could be fired via a user interaction (which, yes, includes pointer events) not to be fired on an element which is inert. Perhaps I can find a better way to say that.

Copy link
Member

@domenic domenic Apr 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't think this should change event dispatch or prevent people from doing dispatchEvent... I think instead inert should be about blocking user interaction from translating into events.

Stated another way, I think it's better if the base EventTarget class does not give special semantics to certain event names, or to whether the EventTarget is actually a HTML Element with a certain content attribute. That seems like a layering violation; EventTarget should just be concerned with a generic eventing system.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I'm not sure we'd want people to be able to dispatch click events programmatically on inert elements, would we?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should stop them... programmatic event dispatch is basically just an indirect way of doing function calls, by coordinating everything through various strings. Whether those strings are named "click" or "myevent" shouldn't, IMO, effect whether this indirect-function-call mechanism works.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmmm. I guess we could try this out, then:

  • Remove the list of forbidden events
  • Include the "topmost event target" re-targeting language
  • Include the existing language in https://html.spec.whatwg.org/#focus-processing-model about not focusing inert elements and note in the inert section that inert elements generally aren't focusable
  • Include the points about find in page and selection potentially being disallowed by the user agent.

That would make inert elements effectively unable to be interacted with via a user interaction, I think.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Did that 鈽濓笍)

source Outdated Show resolved Hide resolved
source Outdated

<li><p>the user agent may prevent the user from selecting text in that node, and may prevent
code calling <code data-x="dom-textarea/input-setSelectionRange">setSelectionRange()</code>
on the node.</p></li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be better defined as a modification of the setSelectionRange() algorithm, as currently it's unclear what this means.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

source Outdated
<span data-x="inert">inertness</span>.</p>
named "inert". This section merely defines an abstract <em>concept</em> of <span
data-x="inert">inertness</span>. See <code data-x="attr-inert">inert</code> for an explanation of
the attribute of the same name.</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd make this something like "See also the inert attribute." if we think we need to keep this note at all.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Member

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great to me. I made some minor editorial tweaks, but I am quite happy with the event dispatching changes. I know @annevk and @smaug---- are a bit more demanding there, so it'll be good to get their take. And of course web platform tests will help.

But from my perspective, this is ready to merge.

source Outdated
is omitted, it will be reset to be the platform default (none or forward).</p>
<p>If <var>element</var> is not <span>inert</span>, changes the selection to cover the given
substring in the given direction. If the direction is omitted, it will be reset to be the
platform default (none or forward).</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the non-normative description of the method. The normative description should also be changed, no?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added an early return into the normative description.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, reading this more closely, shouldn't this affect the other selection methods as well?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved it into the "set the selection range" algorithm, what do you think?

source Outdated
<li>
<p>If an event would be fired as a result of user input, such that the
<span>inert</span> element would be the <span data-x="topmost-event-target">topmost event
target</span>, an alternative <span data-x="event-target">event target</span> must be found as
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is topmost event target always an element? The earlier text suggests it could be a text node too.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://w3c.github.io/uievents/#topmost-event-target says "[t]he topmost event target MUST be the element highest in the rendering order which is capable of being an event target", so it seems like we can assume it is always an element.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe? Not sure UI Events can be trusted. But that means the earlier text is wrong, no?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not necessarily. The following two points specifically concern text nodes:

The user interaction events, agent may ignore the node for the purposes of text search user interfaces (commonly known as "find in page"), page"); and

The user agent may prevent the user from selecting text in that node.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is unclear is if the current text applies when it's not an element that is inert or if it should be ignored in that case. (Perhaps there's no way to get UI events to fire on non-elements though, but then it comes back to the synthetic cases and I've somewhat forgotten what we decided on there.) It's rather hard to revisit this every couple of weeks and remember all the various details. 馃槦

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On reflection, I'm happy to change it to Node, seems like that would be the most inclusive and not inaccurate.

source Outdated
<li><p>Add <var>candidate</var> to <var>ineligible</var>.</p></li>
<li><p>Let <var>candidate</var> be the element which would be the <span
data-x="topmost-event-target">topmost event target</span> if all the elements in
<var>ineligible</var> were excluded from consideration.</p></li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you'd have to perform hit testing again? In particular, if a position a div under an inert element, that div element would become candidate?

Do we have tests for that?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Working on tests, yeah.

The intent is that if you position a div which is not an ancestor under the inert element, that div would not be targeted. The old wording, and indeed the old implementation in blink, would have targeted the event at the non-ancestor div, as does pointer-events: none.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clarification, sorry - the div would become candidate, but would be added to ineligible as it is not an ancestor.

I've looked at implementing this in Blink, and it seems to be possible to do without performing redundant hit testing at least in our codebase - rather, you continue the hit testing process until a suitable candidate is found.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah right, thanks. Ideally this shares infrastructure with https://drafts.csswg.org/cssom-view/#dom-document-elementsfrompoint I think, which should use the same primitive.

This also needs to be rephrased a bit using "Set candidate to" as you already initialized it earlier.

Copy link
Author

@alice alice May 2, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally this shares infrastructure with https://drafts.csswg.org/cssom-view/#dom-document-elementsfrompoint I think, which should use the same primitive.

Do you mean the implementation, or the spec? The implementation does indeed share infastructure.

This also needs to be rephrased a bit using "Set candidate to" as you already initialized it earlier.

Done, thanks.

(Edited because I originally pasted the wrong thing into my quote)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant both.

Copy link
Author

@alice alice May 14, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a lot of spec technical debt to be cleared up around hit testing.

UIEvents says:

The topmost event target MUST be the element highest in the rendering order which is capable of being an event target. In graphical user interfaces this is the element under the user鈥檚 pointing device. A user interface鈥檚 hit testing facility is used to determine the target. For specific details regarding hit testing and stacking order, refer to the host language.

As far as I know, "hit testing" is not defined for HTML.

The elementsFromPoint definition says:

For each layout box in the viewport, in paint order, starting with the topmost box, that would be a target for hit testing at coordinates x,y even if nothing would be overlapping it, when applying the transforms that apply to the descendants of the viewport, append the associated element to sequence.

without even attempting to define "hit testing" or "paint order".

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated
<li><dfn data-x="event-compositionupdate" data-x-href="https://w3c.github.io/uievents/#event-type-compositionupdate"><code>compositionupdate</code></dfn> event</li>
<li><dfn data-x="event-compositionend" data-x-href="https://w3c.github.io/uievents/#event-type-compositionend"><code>compositionend</code></dfn> event</li>

<li>The <dfn data-x="event-target" data-x-href="https://w3c.github.io/uievents/#event-target">event target</dfn> concept</li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should add this reference as it's rather confusing and duplicative of the DOM Standard.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, the term event target is not actually defined in the DOM standard, and the way I'm using it refers specifically to the sense used in UIEvents.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, but I think we need to find some other way as UI Events really shouldn't define this term and we shouldn't take a new dependency on that "flaw".

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem like a reasonable objection, to be honest. I don't think there is another way (if you think of one, please let me know), and I don't think it affects implementability.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to discuss this further, but I don't think adding a dependency on a bug in UI Events is a good strategy.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The bug being that UIEvents defines this term?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per my understanding of the setup here all of this happens before the dispatch algorithm. The dispatch algorithm is handed a target and an event, but it might fiddle with these as it sees fit (e.g., to account for shadow trees).

The manipulation you define is therefore about the eventual input for the dispatch algorithm at which point you can't really speak about an event target. And UI Events also shouldn't define the term the way it does because that gives the impression you are able to manipulate it in this manner.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. Leaving aside "topmost event target", the only references to "event target" are these two, in the retargeting rules:

... an alternative event target must be found as follows:

If candidate is not null, let candidate be the new event target.

I agree that the manipulation is about the eventual input for the dispatch algorithm. The input for these steps is what the UIEvents spec refers to as the "topmost event target" (really more a potential event target), and the output is the input to the dispatch algorithm.

I think this is correct; we only want to do this manipulation when there is hit testing involved, not as part of the dispatch algorithm in general. Effectively, we want to change the output of the hit testing.

source Outdated Show resolved Hide resolved
source Outdated

<ul>
<li>
<p>If an event would be fired as a result of user input, such that the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear what this would count. E.g., form submission can be the result of user input, can that be prevented?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would the form be the topmost event target in that case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's still not entirely clear to me what topmost event target means.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A better question, to help us figure this out: what user input would cause a form to be submitted?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There might be a click somewhere or some such (though I suppose even click is not technically user input).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can read that in two ways:

  1. The user clicks at the location of the submit button within the form.
    • In that case, the submit button is the topmost event target, and since it is within the form and the form is inert, the click event is retargeted, possibly at the form's parent element (depending on the circumstances which led to the form being inert).
  2. The user clicks at the location of a non-inert button outside the form, which would have the effect of submitting the form due to javascript running in its click event handler.
    • In that case, the button is the topmost event target, and the click event is fired as a result of the user interaction since the button is not inert.

I'm guessing you're thinking of the second case? I guess you could argue that in that case, the form submission event is "as a result of user input", making "topmost event target" ambiguous, but I don't know that it would be a likely interpretation.

@alice
Copy link
Author

alice commented Apr 17, 2019

Just a quick comment to say thanks for the thorough review.

I'll be out for the next week and a half so it might take me a bit to get back to all of it, but just wanted to say it's well appreciated, and in particular that I'm planning to work on the WPT tests for the new behaviour (including retargeting) soon.

@alice
Copy link
Author

alice commented May 2, 2019

Sorry for all the noise, I am so bad at github. Anyway, I've tried to address all your comments (WPT tests are still WIP) - thanks again!

@alice
Copy link
Author

alice commented May 6, 2019

(Not sure why the build failed; it passed for me locally. Would it be possible to re-run?)

@domenic
Copy link
Member

domenic commented May 7, 2019

Sorry for the delay; build re-started, and filed whatwg/html-build#194 to track making the script more resilient to network failures.

@asurkov
Copy link

asurkov commented Jul 31, 2020

I think this hasn't been merged as it only has one implementation so far.

Firefox 81 makes a second implementation, see https://bugzilla.mozilla.org/show_bug.cgi?id=1655722

@domenic
Copy link
Member

domenic commented Jul 31, 2020

Excellent! Do either Firefox or Chrome have plans to ship?

@carmacleod
Copy link
Contributor

carmacleod commented Aug 24, 2020

@asurkov Just to confirm, will inert be behind a flag in Firefox 81?

@alice Is inert still behind a feature flag in Chrome?

[Edit, April 9, 2021: Yes, still behind a flag in both Firefox and Chrome. The only mainstream browser that doesn't have an implementation yet is webkit/Safari].

@asurkov
Copy link

asurkov commented Aug 31, 2020

@asurkov Just to confirm, will inert be behind a flag in Firefox 81?

correct, Firefox 81 will have html5.inert.enabled preference to turn the feature on

Excellent! Do either Firefox or Chrome have plans to ship?

I think there are at least two blocking issues before it can be shipped in Firefox, which are

Base automatically changed from master to main January 15, 2021 07:57
@alice alice mentioned this pull request Feb 16, 2021
1 task
<li><p>Let <var>ineligible</var> be an empty list.</p></li>
<li>
<p>While <var>candidate</var> is <span>inert</span>, or <var>candidate</var> is not an an
ancestor of <var>originalElement</var> in the <span>flat tree</span>:</p>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the use of flat tree here makes much sense. This would mean that an element becomes inert if it's assigned to a slot which is inert. I don't think that's right given inert is a content attribute. We typically don't let content attribute on an element affecting slotted nodes or their descendants.

I think what we want here instead is the concept of shadow-including inclusive ancestor.

@annevk
Copy link
Member

annevk commented Mar 10, 2022

Closing as part of 755ae90 (#7134).

@annevk annevk closed this Mar 10, 2022
mfreed7 pushed a commit to mfreed7/html that referenced this pull request Jun 3, 2022
Based on work in whatwg#4288 by Alice Boxhall.

Tests: https://github.com/web-platform-tests/wpt/tree/master/inert.

Closes whatwg#5650.

Co-authored-by: Alice Boxhall <aboxhall@chromium.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants