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

cathiechen has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-contain-2]: Should the first `contentvisibilityautostatechange` event be fired without knowing if the element is close to the viewport ==
According to [1]
> The contentvisibilityautostatechange event is fired on an element with [content-visibility: auto](https://drafts.csswg.org/css-contain/#propdef-content-visibility) style when the rendering state changes and the element either becomes or stops being [relevant to the user](https://drafts.csswg.org/css-contain/#relevant-to-the-user).

It does not specify if `contentvisibilityautostatechange` event should be fired when `content-visibility: auto` is added to the element. Tested one Chromium, WebKit, and Gecko, the behavior is synchronizing, all of them are firing when the value of [relevant to the user](https://drafts.csswg.org/css-contain/#relevant-to-the-user) is changed from empty to some value.

The followup question is when to fire the first `contentvisibilityautostatechange` event. The value of [relevant to the user](https://drafts.csswg.org/css-contain/#relevant-to-the-user) is determined by several factors.

> An element is relevant to the user if any of the following conditions are true:
> 1. The element is [close to the viewport](https://drafts.csswg.org/css-contain/#close-to-the-viewport).
> 2. Either the element or its [contents](https://www.w3.org/TR/CSS21/conform.html#content) are [focus](https://html.spec.whatwg.org/multipage/interaction.html#focus)ed, as described in the focus section of the HTML spec.
> 3. Either the element or its [contents](https://www.w3.org/TR/CSS21/conform.html#content) are selected, where selection is described in the [selection API](https://www.w3.org/TR/selection-api/#dfn-selection)
> 4. Either the element or its [contents](https://www.w3.org/TR/CSS21/conform.html#content) are placed in the [top layer](https://drafts.csswg.org/css-position-4/#document-top-layer).
> 5. The element has a [flat tree](https://drafts.csswg.org/css-scoping-1/#flat-tree) descendant that is involved in a view transition.

According to [2], whether it is [close to the viewport](https://drafts.csswg.org/css-contain/#close-to-the-viewport) could not be determined in at least one frame. Should the first `contentvisibilityautostatechange` event be fired without this value?

I personally think not. The first `contentvisibilityautostatechange` event should be fired after we get the value of [close to the viewport](https://drafts.csswg.org/css-contain/#close-to-the-viewport), otherwise it is redundant, and a new event might be fired in the next frame. Furthermore, there is chance to call intermittent issue, sometime fire one event and sometime fire two.

The content-visibility-with-top-layer-008.html in [the Gecko Patch](https://phabricator.services.mozilla.com/D198602) could demonstrate this issue. The intermittent issue could be reproduced very easily.

cc @emilio @vmpstr @nt1m @fredw

[1] https://drafts.csswg.org/css-contain/#content-visibility-auto-state-change
[2] https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model:content-visibility-auto

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9803 using your GitHub account


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

Received on Tuesday, 16 January 2024 18:46:32 UTC