CSS content-visibility content relevancy section should be in the HTML spec.

[emilio]

What is the issue with the HTML Standard?

https://drafts.csswg.org/css-contain/#cv-notes has:

Specifically, such changes will take effect between steps 13 and 14 of update the rendering step of the Processing Model (between “run the animation frame callbacks” and “run the update intersection observations steps”).

However run the animation frame callbacks is now step 14, and there's step 15 which takes care of updating style and layout and so on, along with ResizeObserver.

I think this should probably happen either right before that loop in step 15, or inside that loop. But it should happen in the HTML step so it doesn't get out of sync and all these steps are well defined...

Any strong opinions? Maybe once per frame at the beginning of that loop is alright.

cc @vmpstr @noamr @Loirooriol @mrobinson

[emilio]

Also last remembered sizes I suppose: https://drafts.csswg.org/css-sizing-4/#last-remembered

[Loirooriol]

See w3c/csswg-drafts#7659 about the timing for setting last remembered sizes

[vmpstr]

For content-visibility, right before step 15 makes sense to me. I'm agnostic as to whether this text should be in HTML. I have a slight preference in keeping all of the elaborations in css-contain-2. Maybe we can add an exported name in HTML and reference that in CSS instead of hardcoding step numbers? (Thanks to @dbaron for that suggestion)

[domenic]

Thanks for the input on the location!

In general we prefer not to have monkey patch specs. See https://annevankesteren.nl/2014/02/monkey-patch and https://w3ctag.github.io/design-principles/#monkey-patching . So it's quite inappropriate to have CSS modify the HTML rendering steps, and we definitely need to move it.

[noamr]

Thanks for the input on the location!

In general we prefer not to have monkey patch specs. See https://annevankesteren.nl/2014/02/monkey-patch and https://w3ctag.github.io/design-principles/#monkey-patching . So it's quite inappropriate to have CSS modify the HTML rendering steps, and we definitely need to move it.

One thing we can do though is export a somewhat generic name from css-contain and refer to that from the HTML spec, leaving the details in the CSS spec (similar to what we do for view transitions).

[emilio]

So I went for something like w3c/csswg-drafts#12105, but I'm not sure I agree on what would be the right place to call this in HTML.

In particular, it seems this would need to happen after the first layout to be deterministic, right? Otherwise whether an element has content-visibility: auto or not depends on whether someone updated layout at the right time.

So this should probably happen around where we do the proximity to the viewport determination... Do you agree @noamr @vmpstr? Or how does Blink deal with this?

Something like tweaking that algorithm to be something like w3c/csswg-drafts@d4c4952, and the HTML spec to do something like #11241 which I just submitted.

Once we're clear on the approach here I need to write some tests of course...

[emilio]

cc @fred-wang too, since he may also be familiar with the topic.

[noamr]

This makes sense to me but deferring to @vmpstr as the subject matter expert.

[vmpstr]

The timing generally makes sense to me, with a caveat on when the effect of the relevant determination takes effect. I left a comment on w3c/csswg-drafts#12105 to explain what I mean.

Related, I think there may be a behavior difference introduced in https://github.com/whatwg/html/pull/11241/files if I understand the intent of w3c/csswg-drafts#12105 correctly.

Previously, the immediate determination of relevant state was a property of each element being considered (if an element has auto and proximity has never been determined, ...). Now it's a property of which iteration of the outer loop we're in.

This makes a difference in the case of nested content-visibility: auto. In the first iteration, because rendering is skipped we only consider the outer element as having a used value of content-visibility: auto. When we determine it's proximity and that it's relevant, we rerun the style & layout parts of the algorithm and discover an inner content-visibility: auto element which has never been previously determined. Prior to the PR, this new determination would also happen synchronously. Now, it happens asynchronously since we're in the second iteration of the loop.

Blink currently implements the behavior before the PR