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

> is `visibility: inert` a possibility? does this need to be its own property? just curious. visibility: hidden already completely removes content from the a11y tree. but often inert content doesn't need to be 100% hidden

Yup, this is definitely a possible form for option 1!

> (though per the guidance I helped at to the HTML spec, we would generally want some visual indicator that the content is not currently meant to be accessible). So a default UA style of some lower level opacity/transparency would probably be good (and then allow authors to override this as needed ).

This is a nice idea, were you thinking that it would actually use opacity, or change the color to have some transparency?

Using opacity is a bit tricky since it implicitly affects the way all descendants paint. E.g.

```html
<style>
  section:not(.active), .inert {
    visibility: inert;
  }
</style>
<section>
  <p>This is some <i>inert</i> content</p>
  <div class="inert">
    <p>This content is also inert</p>
  </div>
</section>
```

If visibility implies / sets `opacity: 0.5`, does it also apply it to those elements inheriting visibility? If so, you'd end up with the `<p>` having an effective 25% opacity, and the inner `<i>` having 12.5% opacity. Even if we had a mechanism to only set it when you explicitly set `visibility: inert` it would probably be surprising that nested inert content is even more transparent. The other issue here is that if we allow making some subtree not inert you'd like it to have full opacity.

As such, I think changing the transparency on the color makes more sense, as it doesn't make its descendants even more transparent and can be easily undone in a `visibility: visible` subtree.

> i'd be warry of doing anything with `opacity: 0` and inertness. i know there's plenty of instances of opacity: 0 in the wild which are being used for visually hidden content that is not meant to be hidden to AT. Making that content inert would likely break a lot of websites.

+1 I agree. We should avoid this as a trigger.

> the only worry i have with that is inadvertently making content not inert when it really should have been. e.g., marking an element as not inert with CSS which makes sense for that component/in the normal document flow - but then a user invokes a modal dialog. Does that content become inert, stay not inert? Maybe if a modal dialog exists in the top layer, any document-level not-inert content becomes inert. But if someone needed a modal dialog AND a notification popover, well that popover is in the top layer now, and if it was marked as being not-inert, then could help solve stuff like [whatwg/html#9936](https://github.com/whatwg/html/issues/9936)

I think the computed inertness should probably take into account more than just this property. E.g. maybe you wouldn't be able to undo inertness when it had been set by the HTML mechanism or dialog.

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


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

Received on Wednesday, 4 September 2024 14:12:46 UTC