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 is 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.

OK makes sense. Would be good to have some clear wording of when we skip the event dispatching in the spec.

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


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

Received on Tuesday, 30 January 2024 14:04:47 UTC