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

>This was pursuing @scottaohara's suggestion https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2310950905 to see if this made sense. However, it does prevent us from explaining how the inert attribute works in any other way than computed magic, whereas if we use a new property we can easily explain it by a UA stylesheet

yeah i'm not at all wedded to that suggestion - it just seemed to make some sense to me... but I don't think it matters to expand on that at this point.

re: @alice's comment
>I'm hesitant on the question of whether it should be possible to "un-inert" content. We went back and forth on this with the attribute as well, I think, and landed on the current behaviour partly for HTML boolean attribute reasons, but also partly because we didn't want to have authors accidentally or deliberately escaping inert and degrading the user experience.

fwiw, i am absolutely agree with the desire to not have authors willy-nilly escape inertness and degrading what should otherwise be straight forward modal experiences.

I am also totally fine with CSS _not_ being the way to do that.  However, there are some legitimate cases where being able to escape inertness (even inertness due to rendering a modal dialog) have been brought up, and it's been frustrating because the use cases can make it difficult, if not prevent, the use of the inert attribute or dialog element.

There are three use cases which I keep encountering / seeing discussion about:
1. arguably the least 'troublesome' would be teaching/touring UI where the page is mostly dimmed except for the feature being highlighted and a popup/over that describes the feature. Generally the popup wouldn't be modal as someone should be able to see/review the feature that's being described - but the rest of the page needs to/should be inert, which is rather complicated to do with the attribute. There are other ways to do this, but they're often complicated to implement... I generally don't encounter teams willing to put in the effort, so the experience is often less than ideal.
1. one thing that has been stopping some component libraries i'm aware of from embracing the dialog element for their modal dialogs is because it makes the whole page inert.  Not that they don't (mostly) want this - but using it means that their solutions for global messaging / live regions fail because they're often placed at the bottom of the DOM... which becomes inert and thus the live regions fired due to activity in the modal dialog don't actually get exposed to the a11y tree.  The ARIA notification API proposal could help some here, but not always...
1. This use case overlaps with 2 a bit, but again related to modal dialogs that contain UI that invokes reusable component library popups (which some have started to try to convert to popovers).  These can include popup notifications (similar to 2, but unique in that they might also contain functionality so simply announcing the content isn't sufficient), or other dynamically populated UI (listbox, menus, etc.) where often the UI is injected at the bottom of the DOM and was positioned with JS to where it needed to show up.  Popover makes this a bit easier, but because the popover originates from the inert page, it too is inert. 

i personally don't think this topic of being able to escape inertness is out of scope for a feature proposing to introduce inertness with CSS.  I'm sorry if this comes across as conflating things, but I see this as an opportunity to resolve these use cases, or maybe get people to think about other more appropriate proposals to do so, if not part of this.

Thanks

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


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

Received on Friday, 27 September 2024 16:01:09 UTC