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.