Re: [csswg-drafts] [css-contain][css-sizing] `content-visibility: auto` kinda broken by not using last remembered size with `contain: size` (#7807)

> `content-visibility: auto` only skips the contents when the element is off the screen by some UA-defined margin. So before determining the position and size of the element, we can't know whether it will be skipped or not, right?

The way this should work is that when a content-visibility: auto lock is first created, we assume (in Blink) that it is skipping contents. It doesn't really matter what we assume at that time tbh, because the spec says

> The initial determination of visibility for [content-visibility: auto](https://www.w3.org/TR/css-contain-2/#propdef-content-visibility) must happen in the same frame that determined an existence of a new content-visibility: auto element.

This means that whether or not we register for ResizeObservation at this point can only cause some churn, but no signals yet. Specifically in Blink, after the patch that I referenced above, we wait until style & layout is done, then determine the true state of the content-visibility. If our initial assumption was wrong, i.e. we should not be skipping contents, then we change the state and synchronously rerun style & layout. This would then unregister from resize observation. All this happens before we issue resize observer callbacks. I think this is what you mean by this can cause extra work, which I think is ok.

In the non-initial determination case, the spec says

> If an element starts or stops [skipping its contents](https://www.w3.org/TR/css-contain-2/#skips-its-contents), this change happens after the requestAnimationFrame callbacks of the frame that renders the effects of the change have run. Specifically, such changes will take effect between steps 13 and 14 of [Update the Rendering](https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering) step of the Processing Model (between “run the animation frame callbacks” and “run the update intersection observations steps”).

With a non-normative explanation:

> Determining the viewport intersection of the element can be done with an internal version of an IntersectionObserver. However, since the observations from this are dispatched at step 14 of Update the Rendering, any changes to the [skipped](https://www.w3.org/TR/css-contain-2/#skips-its-contents) (and thus painted) state will not be visible to the user until the next frame’s processing. For this reason, updating the skipped state, including containment adjustments, is deferred to that frame as well. This ensures that script accessing, for example, the containment value of the element between these two events (internal intersection observation and skipped state update) will retrieve values consistent with current painted state and not cause any forced layouts.

This means that if we, for example, registered for the resize observation and later determine that the state should be skipping the contents, that state change doesn't take effect until the next frame so the resize observation should be correct, and we will unregister from the observation on the next frame.

So all in all, using "skips its content" as a condition to whether to do resize observations seems fine to me

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


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

Received on Friday, 30 September 2022 15:13:43 UTC