- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Aug 2024 19:10:53 +0000
- To: public-css-archive@w3.org
Thanks for the context @jcsteh, this makes sense. I agree that we should at minimum have strong guidance on how to use this to avoid its misuse. Options based on 2 would nicely ensure that content that a11y APIs can see the same content that sighted users can. I'd be interested to determine to what extent we might be able to automatically infer the other use cases @emilio had in mind. E.g. we could also apply inertness on other common cues like `opacity: 0` or `visibility: hidden` though either of these has challenges: * At what opacity is something considered no longer visible? * `visibility: hidden` can be overridden in a subtree so you'd have to ensure that visible content within is not inert. It's worth noting that our [resolution in #8389](https://github.com/w3c/csswg-drafts/issues/8389#issuecomment-1460542364) technically allows making content inert via CSS ([demo](https://codepen.io/flackr/pen/vYqjWRJ)): ```css .inert { /* Immediately starts a transition to display: none */ transition: display 10000000s allow-discrete; /* Since the underlying display value is none, this is treated as inert per resolution in #8389 */ display: none; @starting-style { /* Starts visible to trigger the transition. */ display: block; } } ``` I think that we should try for an automatic mechanism to the extent we can detect visible content (option 2). I'm open to suggestions for how to recognize other cases where developers want to have displayed content that is not meant to be seen or interacted with. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2307665459 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 23 August 2024 19:10:54 UTC