- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Jul 2022 23:16:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain-3] Proposal: Add an event to fire when content-visibility: auto state changes`, and agreed to the following: * `RESOLVED: Add the new event with the name ContentVisibilityAutoStateChanged` * `RESOLVED: Add a note about potential issues for a11y` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-contain-3] Proposal: Add an event to fire when content-visibility: auto state changes<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/7384<br> <dael> vmpstr: This is a prop for a new event for content-visibility: auto<br> <dael> vmpstr: content-visibility: auto right now skips rendering when element is offscreen or not relevant to use<br> <dael> vmpstr: Prop is expose and event that fires when this state changes<br> <dael> vmpstr: Motivation is some of the partner feedback. In particular they want to skip additional work when element is offscreen such as react update. Event is convenient way to do so<br> <dael> Rossen_: Catching up, did we establish event name?<br> <dael> vmpstr: We can talk about name. I have proposals and TabAtkins commented more explicit and verbose is better which I'm fine with<br> <dael> Rossen_: Backing up, can you remind me for the content-visibility: auto elements nested inside do they participate in a11y tree?<br> <dael> vmpstr: content-visibility: auto elements do participate in a11y. They're exposed as visible.<br> <dael> Rossen_: From PoV of a11y these events and content-visibility: auto has no meaningful meaning?<br> <chrishtr> whether the content is skipped affects layout<br> <dael> vmpstr: The event itself doesn't. The only potential difference is if script does something in response tot he event such as skipping react updates that eventually cause a different a11y tree.<br> <dael> Rossen_: Thanks. That's what I wanted to decipher here. If, as an author, I'm pausing a bunch of work on the event and I'm aware what impact pausing would have on a11y that could degrade the experience of assistive tech<br> <Rossen_> q?<br> <chrishtr> q+<br> <heycam> q+<br> <dael> vmpstr: It is a possibility. Currently the solution is to add own intersection observer and do the same thing but impossible to guess the margin content-visibility: auto has internally. but this could be done with intersection observer<br> <dael> chrishtr: Clarifying your point, Rossen_. I think you were saying exposing the event makes it easier for author to remove offscreen content from DOM?<br> <dael> Rossen_: That would be one more kind of aggressive change, yes<br> <dael> chrishtr: Yeah. Then I would repeat that it is already possible and virtual scrollers do it. Main value is it allow them to play with perf benefits. But if a site unmounts DOM that's far offscreen it would be less info for a11y tech<br> <Rossen_> ack chrishtr<br> <Rossen_> ack heycam<br> <dael> heycam: By the sounds of it this can be achieved using intersection observer already by watching for the same changes, maybe with some additional checks for focus. Wondering about firing of events and which lements fired to. One difference with intersection observer is you register on an element and sounds like this event should be dispatched to every element<br> <dael> heycam: Could be like the focus state of an element changes, would that mean have to dispatch a separate event to each ancestor?<br> <dael> vmpstr: I think I would like to dispatch this event to an element that has content-visibility: auto style on it when relevance of that element changes. Spec is element is relevent if in flat tree has an element that has focus. It's if the content-visibility: auto element with the element in the subtree has focus<br> <dael> heycam: I see. Okay<br> <Rossen_> q?<br> <dael> Rossen_: Additional feedback?<br> <dael> Rossen_: I guess you're looking for resolution to add this event, with name and shape tbd?<br> <dael> vmpstr: If no obj to content-visibility-auto-state-change I'd like to resolve on that. But also happy to resolve to add event<br> <dael> Rossen_: If no other feedback or additional comments to vmpstr then are there any objections to exposing such event?<br> <dael> Rossen_: Objections to ContentVisibilityAutoStateChanged as the name<br> <dael> heycam: Is there a way to query the content-visibility auto state?<br> <dael> vmpstr: No so the event would have that information on it<br> <dael> Rossen_: Hearing no objection on event or name<br> <dael> RESOLVED: Add the new event with the name ContentVisibilityAutoStateChanged<br> <dael> Rossen_: Still a bit concerned about if there is a way to add author guidance about potential degredation of a11y experience. I don't think that's the event itself, but the event might make it more confortable<br> <dael> vmpstr: Can add a note to the spec next to the event<br> <dael> Rossen_: Would love that<br> <dael> Rossen_: Thanks<br> <dael> RESOLVED: Add a note about potential issues for a11y<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7384#issuecomment-1176847043 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 July 2022 23:16:49 UTC