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.

Sign up for GitHub

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

Jump to bottom

inert attribute #610

Closed
1 task done
alice opened this issue Feb 16, 2021 · 8 comments
Closed
1 task done

inert attribute #610

alice opened this issue Feb 16, 2021 · 8 comments
Assignees
@hober @LeaVerou
Labels
Resolution: satisfied The TAG is satisfied with this design Topic: HTML Venue: WICG
Milestone
2021-03-22-week

Comments

@alice
Copy link

alice commented Feb 16, 2021 •
edited

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:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines: No deadline, but hoping to ship soon. (I didn't realise until I was filling out the intent to ship that I never actually requested a TAG review, to my surprise.)
  • The group where the work on this specification is currently being done: WICG, WHATWG
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG
  • Major unresolved issues with or opposition to this specification:
  • This work is being funded by: Google

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
@LeaVerou LeaVerou self-assigned this Feb 16, 2021
@LeaVerou
Copy link
Member

Hi @alice! 👋🏼

Looking at the explainer, I'm missing some examples of how this is supposed to be used. If it's used on <body>, wouldn't it make the entire subtree inert, including the <dialog> itself? There often is a natural container for all content that excludes dialogs, popups, etc, but not always, so libraries cannot depend on it, and would need to introduce their own wrapper element, which is fairly intrusive. I suppose this is why <dialog> in the spec isn't actually defined in terms of the inert attribute?

Given that inert is currently a boolean attribute, it doesn't look like there's a way to override it on descendant subtrees. However, a way to do so could be quite useful to address the many cases where the inert subtree(s) contain the blocking elements or vice versa. Another example that comes to mind is UI to edit parts of an HTML page in place (e.g. a social media profile), by appending form elements within the elements being edited. One wants the parts of the page that are being edited to be inert, but the editing controls inside them to be interactive.

@plinss plinss added this to the 2021-02-22-week milestone Feb 17, 2021
@robdodson
Copy link

robdodson commented Feb 17, 2021 •
edited

Hey @LeaVerou, @alice and I were just chatting about this in a call as a similar question came up on the WICG repo:
WICG/inert#165

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.

@dylanb
Copy link

dylanb commented Feb 18, 2021

@robdodson @alice the spec does not specify what happens to the focus when an element with the focus becomes inert. Should it?

@domenic
Copy link
Member

domenic commented Feb 18, 2021

@robdodson @alice the spec does not specify what happens to the focus when an element with the focus becomes inert. Should it?

This is actually already in the HTML spec, covered as a general case: https://html.spec.whatwg.org/#focus-fixup-rule

@torgo
Copy link
Member

torgo commented Feb 22, 2021

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.

@alice
Copy link
Author

alice commented Feb 23, 2021 •
edited

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:

  • Firstly, it means a straightforward boolean attribute can be used, instead of a string-based pseudo-boolean.
  • Secondly, it means there's no need to define any kind of precedence or !important type rule to ensure that no content becomes "un-inert" when it's not supposed to. It makes it trivially easy to reason about: if something has an ancestor with inert set (or is within an <iframe> within an inert subtree, etc), it is inert.

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 inert on it. However, the popularity of the polyfill suggests that developers haven't found this to be an unreasonable burden.

There is some discussion on this topic on an issue thread. In particular:

Maciej Stachowiak wrote:

... the inability to escape inert from within a subtree seems like a feature not a bug.

I followed up:

... on my backlog of "ideas to write up as concrete proposals" is a top layer API which would explain both the "inert everything else" and the stacking behaviour of dialogs. I think those two things belong together, as the "inert everything else" behaviour is visually indicated by the combination of stacking and backdrop. It would obviously reuse the definition of "inert" used by both <dialog> and the inert attribute.

--

Edit: @robdodson had some extra thoughts on this issue:

Yes, a modal dialog has to be outside of the inert container. We did discuss the idea of letting items inside of the inert container "punch through" but we were concerned that would be chaotic. For example, imagine you load an ad (or some other third party iframe) into a page, and it uninerts itself (or something inside of itself).

@alice
Copy link
Author

alice commented Mar 15, 2021

Little worried this has landed in the abyss :)

@plinss plinss added Progress: propose closing we think it should be closed but are waiting on some feedback or consensus and removed Progress: in progress labels Mar 23, 2021
@LeaVerou
Copy link
Member

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.
Therefore, we will close this. Thank you for filing it and please let us know if we can be of any more help.

@LeaVerou LeaVerou added Resolution: satisfied The TAG is satisfied with this design and removed Missing: security & privacy review Progress: propose closing we think it should be closed but are waiting on some feedback or consensus labels Mar 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hober hober

@LeaVerou LeaVerou

Labels
Resolution: satisfied The TAG is satisfied with this design Topic: HTML Venue: WICG
Projects
None yet
Milestone
2021-03-22-week
Development

No branches or pull requests
8 participants
@hober @dylanb @alice @LeaVerou @torgo @domenic @robdodson @plinss