Re: [csswg-drafts] [css-ui] Support setting offscreen content inert (#10711)

https://silkhq.co - creator https://x.com/brunostasse
the following are notes from conversations with them:

When asked why they didnt use popover or dialog, the response was a set of use cases that CSS interactivity would be the right fit for.

**Issues with `inert`:**
1. It's often too strong, similar to shadowDOM, where exceptions become difficult because the value of the feature is to not make exceptions
2. Javascript required to toggle, or in complex cases, javascript to walk trees and conditionally apply (something css selectors would easily do)
3. There's often needs for setting inert to a subtree and being able to create holes in it (what the author call islands of interactivity in Silk), or we may call "donut inert" with CSS interactivity

**Use cases for consideration to the group:**
1. [ParallaxPage](https://silkhq.co/#example-parallax-page-h1) - "the whole document is inert, but not the content of the ParallaxPage, and not the content of the top bar (which was present before opening the page). This is complicated to get with inert because you have to walk the whole tree to add it exactly where you need so the precise elements you need to remain interactive are not wrapped in it. Consider an `inert-outside` feature? Ideally you'd be able to set it to several elements, and they would be the only elements you can interact with on the page. It's better than having to set inert at the top level, because to do that declaratively you need a top level html element." 
2. Stack Management: “I also may want to open sheets on the page without making them front most, like adding cards in the back of a stack. With these API they would end up at the front of the stack. I don't yet handle this feature by I want in the future”
4. A dialog being shown but you want to keep the primary nav bar interactive (i guess suggest using popover?)
5. Integration with 3rd party libs: “These APIs also don't work well with third party overlay, like browser extensions; they can’t be accessed if they don't use the new primitives as well”. 
6. "I also have a use case where I need inert > interactivity > inert > interactivity. That's a bottom sheet which itself contains a page. It should be inert outside the bottom sheet, then inert inside of the content part of the bottom sheet, but not its top bar, and then interactive inside of the page."

So this is all even trickier when you stack pages, sheets, etc. A lot of scenarios are possible.

Having it in CSS would be very useful to be able to set it based on media/container queries and other selectors on first render.

Everything is better in CSS anyway because of this reason. HTML don't have queries and selectors, so it requires JS for everything.

<end of Bruno's comments />

[Dialog that's been shown modally but a notification/toast comes in…](https://www.tiktok.com/@syntaxfm/video/7410807074227064094). Inert causing people to do wierd stuff to make the UX work

We're seeing very slow adoption for Dialog because of both inert complexity of when it's the right choice, it's power, the lack of easy stacking of multiple items in the top layer and the lack of library adoption. The biggest issue tending to be inert, and folks feeling timid or not knowing you can use dialog non-modally, but also, confusion about why and when you need to orchestrate all this focus. Next biggest is that in your app, if you put 1 thing in the top layer, you tend to have to start putting everything that overlays in a top layer: aka, it doesnt have a good slow adoption story, it's you either put all things in there (tooltips that need to show on top of a modal dialog, multi-layering partial views that open other partial views, etc)

There's also the use case difference between inert and interactivity, where interactivity isnt a CSS replacement of inert, it offers subtly different results which are helpful to authors who are well intentioned and orchestrating lots of dynamic focus moments (like with Silk and many of it's demos).

**For CSS overflow markers:**
Being able to "un-inert" the interactivity is paramount so that the offscreen content (cards or whatever) is marked as not being interactive (this allows the keyboard to flyover a long list of interactive items), but the `::scroll-marker` generated for it inherits the non-interactivity thus becoming a dot that can't be clicked or interacted with. The fix is to ensure restore interactivity for the markers 👍🏻 then, users can click or use the keyboard in the dots, which scroll content into view and when it's in view it's interactive. boom, it's a very healthy relationship, all relating to "scroll affordances" as provided by the markers which help aid content discovery and provide hints as to the size of the content in the scroller.

there's a lot of folks out there with very good intent on shipping meaningful keyboard and screen reader interactions who are struggling with the current tools. 

**tldr;**
- adoption from beautiful libraries is low because the current feature is both strong and rough to juggle
- folks need an escape hatch so they can ensure interactive content is accessible during complex multi-moment overlays are happening
- css interactivity provides the flexibility and adaptiveness that authors are looking for so they can provide meaningful focus and keyboard experiences
- css markers are a great use case of when you have complex conditional interactivity desires and how a css driven interactivity feature (not necessarily a css inert feature) arent just valuable but required

-- 
GitHub Notification of comment by argyleink
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2762007667 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 28 March 2025 17:31:47 UTC