-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re add inert #4288
Re add inert #4288
Changes from all commits
617566c
fea0edb
4faaca3
0819a4b
c173dae
5da910e
2f1b841
a69465a
24ae880
825167f
2215756
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3053,7 +3053,10 @@ a.setAttribute('href', 'https://example.com/'); // change the content attribute | |
<li><dfn data-x="event-keydown" data-x-href="https://w3c.github.io/uievents/#event-type-keydown"><code>keydown</code></dfn> event</li> | ||
<li><dfn data-x="event-keypress" data-x-href="https://w3c.github.io/uievents/#event-type-keypress"><code>keypress</code></dfn> event</li> | ||
<li><dfn data-x="event-keyup" data-x-href="https://w3c.github.io/uievents/#event-type-keyup"><code>keyup</code></dfn> event</li> | ||
</ul> | ||
|
||
<li>The <dfn data-x="event-target" data-x-href="https://w3c.github.io/uievents/#event-target">event target</dfn> concept</li> | ||
<li>The <dfn data-x="topmost-event-target" data-x-href="https://w3c.github.io/uievents/#topmost-event-target">topmost event target</dfn> concept</li> | ||
</ul> | ||
|
||
<p>The following features are defined in <cite>Touch Events</cite>: <ref spec=TOUCH></p> | ||
|
||
|
@@ -55125,6 +55128,8 @@ MIT Room 32-G524 | |
apply">does not apply</span> to this element, throw an | ||
<span>"<code>InvalidStateError</code>"</span> <code>DOMException</code>.</p></li> | ||
|
||
<li><p>If this element is <code>inert</code>, return.</p></li> | ||
|
||
<li><p><span>Set the selection range</span> with <var>start</var>, <var>end</var>, and | ||
<var>direction</var>.</p></li> | ||
</ol> | ||
|
@@ -72506,26 +72511,63 @@ END:VCARD</pre> | |
|
||
<h3>Inert subtrees</h3> | ||
|
||
<p class="note">This section <strong>does not</strong> define or create any content attribute | ||
named "inert". This section merely defines an abstract <em>concept</em> of | ||
<span data-x="inert">inertness</span>.</p> | ||
<p class="note">See also <code data-x="attr-inert">inert</code> for an explanation of | ||
the attribute of the same name.</p> | ||
|
||
<p>A node (in particular elements and text nodes) can be marked as <dfn>inert</dfn>. When a node | ||
is <span>inert</span>, 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 | ||
<span>find-in-page</span>, and may prevent the user from selecting text in that node. User agents | ||
should allow the user to override the restrictions on search and text selection, however.</p> | ||
|
||
<p class="example">For example, consider a page that consists of just a single <span>inert</span> | ||
paragraph positioned in the middle of a <code>body</code>. If a user moves their pointing device | ||
from the <code>body</code> over to the <span>inert</span> paragraph and clicks on the paragraph, | ||
no <code data-x="event-mouseover">mouseover</code> event would be fired, and the <code | ||
data-x="event-mousemove">mousemove</code> and <code data-x="event-click">click</code> events would | ||
be fired on the <code>body</code> element rather than the paragraph.</p> | ||
is <span>inert</span>, then:</p> | ||
|
||
<ul> | ||
<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 | ||
follows:</p> | ||
<ol> | ||
<li><p>Let <var>originalElement</var> be the <span data-x="topmost-event-target">topmost event | ||
target</span> for the event.</p></li> | ||
<li><p>Let <var>candidate</var> be the same element.</p></li> | ||
<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> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||
<ol> | ||
<li><p>Add <var>candidate</var> to <var>ineligible</var>.</p></li> | ||
<li><p>Set <var>candidate</var> to 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, or null if no such element | ||
exists.</p></li> | ||
</ol> | ||
</li> | ||
<li><p>If <var>candidate</var> is not null, let <var>candidate</var> be the new <span | ||
data-x="event-target">event target</span>.</p></li> | ||
<li><p>Otherwise, do not fire the event.</p></li> | ||
</ol> | ||
</li> | ||
|
||
<li><p>The user agent may ignore the node for the purposes of text search user interfaces | ||
(commonly known as "find in page"); and</p></li> | ||
|
||
<li><p>The user agent may prevent the user from selecting text in that node.</p></li> | ||
</ul> | ||
|
||
<p>User agents may allow the user to override the restrictions on search and text selection, | ||
however.</p> | ||
|
||
<p class="example">Consider a page that consists of just a single <span>inert</span> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think this is particularly clear as it would seem that removing the attribute has no effect. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Added a clarification earlier on that an element is not inert by default. I think that covers the removal case. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, you'll need to define how manipulation works explicitly. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are you able to point me to another attribute which has addition/removal steps? I'm not quite sure what you're looking for here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. E.g., the slot attribute in the DOM Standard. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks, taking a look at that! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmmm I had a look and I'm still not quite clear on what the attribute change steps would be here - it seems like they would be trivially "mark as inert" and "mark as not inert", which seems to be already captured here. For example, There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't really see how it's captured here. There's no requirement to unmark anything? (muted is defined by a bunch of indirection, but eventually has "While the muted IDL attribute is set to true, the media element must be muted." which isn't great, but is more clearly conditional than the setup here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't follow how it's more clearly conditional. The phrasing seems pretty parallel to me: "When an element has an inert attribute, the user agent must mark that element and all its shadow-including descendants as inert." The only difference is using "when" instead of "while", and "has an inert attribute" instead of "the muted IDL attribute is set to true". |
||
<code>button</code> positioned in the middle of a <code>body</code>. If a user clicks on the | ||
button, the <code data-x="event-click">click</code> event would cause no event listeners on | ||
<code>button</code> to be run, and the event would instead be targeted at the <code>body</code> | ||
element.</p> | ||
|
||
<p class="note">When a node is inert, it generally cannot be focused. Inert nodes that are <span | ||
data-x="concept-command">commands</span> will also get disabled.</p> | ||
|
||
<p>User agents should show the default cursor when a user indicates an element in an inert subtree | ||
using a pointing device.</p> | ||
|
||
<p>By default, an element is not <span>inert</span>.</p> | ||
|
||
<p>While a <span>browsing context container</span> is marked as <span>inert</span>, its | ||
<span>nested browsing context</span>'s <span>active document</span>, and all nodes in that | ||
<code>Document</code>, must be marked as <span>inert</span>.</p> | ||
|
@@ -72548,7 +72590,27 @@ END:VCARD</pre> | |
data-x="top-layer-add">adding</span> the <code>dialog</code> element to its <span>node | ||
document</span>'s <span>top layer</span>.</p> | ||
|
||
<h4>The <dfn data-x="attr-inert"><code>inert</code></dfn> attribute</h4> | ||
|
||
<p>The <code data-x="attr-inert">inert</code> attribute is a <span>boolean attribute</span> that | ||
indicates, by its presence, that the element and all its shadow-including descendants is to be | ||
made <span>inert</span>.</p> | ||
|
||
<p w-nodev>While an element has an <code data-x="attr-inert">inert</code> attribute, the user | ||
agent must mark that element and all its <span>flat tree</span> descendants as | ||
<span>inert</span>.</p> | ||
|
||
<p class="note">By default, there is no persistent visual indication of a subtree being inert. | ||
Authors are encouraged to clearly mark what parts of their document are active and which are | ||
inert, to avoid user confusion. In particular, it is worth remembering that not all users can see | ||
all parts of a page at once; for example, users of screen readers, users on small devices or with | ||
magnifiers, and even users just using particularly small windows might not be able to see the | ||
active part of a page and might get frustrated if inert sections are not obviously inert. For | ||
individual controls, the <code data-x="attr-fe-disabled">disabled</code> attribute is probably | ||
more appropriate.</p> | ||
|
||
<p>The <dfn data-x="dom-inert"><code>inert</code></dfn> IDL attribute must <span>reflect</span> | ||
the content attribute of the same name.</p> | ||
|
||
<h3>Tracking user activation</h3> | ||
|
||
|
There was a problem hiding this comment.
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 have to state this as it should be redundant with the style sheet requirements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you clarify? What are the style sheet requirements?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there are any rendering requirements those should be in the Rendering section described in terms of CSS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't quite follow, sorry. Do we require implementers to implement this in terms of the user agent stylesheet?