-
Notifications
You must be signed in to change notification settings - Fork 55
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
inert attribute #610
Comments
Hi @alice! 👋🏼 Looking at the explainer, I'm missing some examples of how this is supposed to be used. If it's used on Given that |
Hey @LeaVerou, @alice and I were just chatting about this in a call as a similar question came up on the WICG repo: A quick example of how we recommend folks use inert is: <body>
<main inert></main>
<div class="dialog"></div>
</body> We did discuss the idea of letting subtree items "uninert" themselves but we were concerned that it might lead to unexpected behaviors like every third-party ad trying to uninert itself. Having said that, I think we both recognize that it would be a pretty useful feature. I don't want to speak for Alice, but I'm pretty open to what the TAG thinks on this point. If folks generally think that the value of letting subtree items break out of the inert tree is useful (and the downsides aren't too great) then maybe we should rethink this bit. |
@robdodson @alice the spec does not specify what happens to the focus when an element with the focus becomes |
This is actually already in the HTML spec, covered as a general case: https://html.spec.whatwg.org/#focus-fixup-rule |
Discussed in breakout this week and it appears a privacy & security questionnaire response is still pending. We've bumped it 2 weeks and hope to have a response back when we revisit it then. |
Thanks, the s&p questionnaire is now linked from the top comment. To Lea's question, about whether this should have a mechanism for overriding inert in sub-trees: I can't find any documentation, unfortunately, but I recall that @robdodson, @bkardell and I gave this quite a bit of thought and decided that, on balance, the inability to override was the right design. This makes the API simple in two ways:
Obviously, this does mean that authors who want to use this for modal UI need to keep the modal outside of the container which has There is some discussion on this topic on an issue thread. In particular: Maciej Stachowiak wrote:
I followed up:
-- Edit: @robdodson had some extra thoughts on this issue:
|
Little worried this has landed in the abyss :) |
We discussed this in the Plenary today and we all agree we are happy with it. The reasoning behind subtrees being unable to un-inert themselves seems sound. |
Wil sha TAG!
I'm requesting a TAG review of the
inert
attribute.A node (in particular elements and text nodes) can be marked 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 find-in-page, 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.
The
inert
attribute is a boolean attribute that indicates, by its presence, that the element and all its shadow-including descendants is to be made inert.Further details:
We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify @alice
The text was updated successfully, but these errors were encountered: