Re: [csswg-drafts] [css-contain-2]: Should the first `contentvisibilityautostatechange` event be fired without knowing if the element is close to the viewport (#9803)

> > > From the spec perspective, adding text that says that if the [proximity to the viewport](https://drafts.csswg.org/css-contain/#proximity-to-the-viewport) is [not determined](https://drafts.csswg.org/css-contain/#not-determined), then don't fire the event sounds good to me. This ensures that we don't fire the event eagerly, since the proximity should be determined at the next update the rendering loop
> > 
> > 
> > Yes, it sounds good to me too.
> 
> The relevancy to the user depends on other things than proximity to the viewport. I understand you are proposing to always delay the event dispatching if the proximity to the viewport is not determined yet (even if say we know the element is focused or selected) as anyway that proximity is determined in the next update of the rendering. That LGTM but just want to make sure this is what is proposed here.

From the implementing side, it seems easier to implement to not fire the event if the [proximity to the viewport](https://drafts.csswg.org/css-contain/#proximity-to-the-viewport) is [not determined](https://drafts.csswg.org/css-contain/#not-determined and there is no other relevancy (not focused or selected). Because, we won't always check focused or selected status when checking the proximity to the viewport.



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


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

Received on Wednesday, 24 January 2024 14:53:09 UTC