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

> That was not the only discussion, there's a bunch of discussion on other PRs. I'm thinking of the multiple HTML PRs where inert tried to be added:

@nt1m Thanks for the context! I'm not sure I understand the root of your concern here. The linked issues are about spec'ing the HTML attribute. Are you saying that because we are moving towards defining inert in HTML it can't also be controlled by CSS? IMO having inertness in CSS does not preclude also having an attribute. E.g. the attribute can be explained by having a UA stylesheet rule:

```css
[inert] {
  interactivity: inert;
}
```

Then the computed inert value is usually based on the attribute but can be overridden. Alternately it could be a `!important` rule to not allow overriding.

> * [Browser vendor feedback WICG/inert#69](https://github.com/WICG/inert/issues/69) (maybe more in that repo)

This is the only issue which makes mention of the possibility of it being controlled by CSS as far as I can see. In particular @othermaciej presented an argument against it being in CSS in https://github.com/WICG/inert/issues/69#issuecomment-489915986 which I'll respond to here given the proposal here is not intended to replace the `inert` attribute but to extend it with CSS stylability.

> Caveat: some personal opinions I haven't discussed with the team. I don't think `inert` would be better expressed in CSS. CSS is about presentation, not behavior. Stuff like `user-select` and `-webkit-user-modify` seems in retrospect kind of regrettable.

As a counter-point, `display: none` also inerts content. IMO, this sets a strong precedent which is even used by the ARIA authoring tutorials [1](https://www.w3.org/WAI/ARIA/apg/patterns/carousel/examples/carousel-2-tablist/) and [2](https://www.w3.org/WAI/tutorials/carousels/working-example/) (linked in the OP as well) that the presentation (style) of content does affect what should be visible in the accessibility tree.

> Also, the inability to escape `inert` from within a subtree seems like a feature not a bug. An `inert` CSS property would not be sufficient for implementing `dialog` either, both because of the ability to escape, and because `dialog` also includes novel stacking behavior.

This is not incompatible with a CSS inertness property. We have examples of both properties which can escape (e.g. `pointer-events: none`, `visibility: hidden`, and properties which can't escape `display: none`, `contain: strict`, `touch-action: none`). Typically properties which can't escape are not inherited, instead implying their state affects their entire subtree just as the inert attribute does. That being said, I could see there being an advantage to being able to escape inertness being able to explain and allow authoring experiences similar to dialog without needing to explicitly use dialog or other top layer APIs.

> it would be good to check with web a11y experts before moving forward.

Happy to loop in a11y experts to the discussion. The intention is to make it easier for authors to meet the guidelines set out as best practices by the ARIA Authoring Practices Guide. Given that these guidelines already make use of `display: none` to inert inactive content it seems reasonable that authors should also be able to easily content in situations where it is not meant to be accessed currently - e.g. needs to be visible in order to animate in.

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


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

Received on Thursday, 22 August 2024 18:43:47 UTC