Intent to Prototype and Ship: content-visibility: auto implies contain-intrinsic-size: auto

[Vladimir Levin]

Contact emails

vmp...@chromium.org

Specification

https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override

Summary

This feature is a result of a CSSWG resolution: https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1440466558 content-visibility: auto is a property that can be used to optimize rendering of off-screen content. However, when rendering is optimized it also means that the size of the element cannot be determined using the descendant information. This is done with size containment. As a result, contain-intrinsic-size was added to help with this. When content-visibility: auto skips contents, contain-intrinsic-size determines its size (roughly as if it had a single child of specified size). contain-intrinsic-size also has an option to add an "auto" keyword which means "if the element has been previously rendered, then use that size; if not, use the specified size". This helps with layout stability by ensuring that elements that come into the viewport and then leave remain the same size as before. This feature tracks forcing contain-intrinsic-size: auto if content-visibility's value is auto.

Blink component

Blink>Paint

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There is a risk of interoperability here, since this changes the behavior of content-visibility: auto and contain-intrinsic-size interaction. Specifically, this forces the layout size of content-visibility: auto elements to be different after it becomes relevant to the user, even when the element starts skipping contents once again. Note that the developer does not have to specify contain-intrinsic-size values, since the default value of "none" can also gain the "auto" keyword. Although this risk exists, I believe the change is for the better, since the ability to size things appropriately under content-visibility has been a challenging piece of content-visibility adoption. Out of httparchive sites that use contain-intrinsic-size, roughly half already use "auto" variety.

Gecko: Shipped/Shipping (https://hg.mozilla.org/mozilla-central/rev/af2192d1c537)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/228)

Web developers: No signals (https://github.com/WebKit/standards-positions/issues/228)

Other signals:

Ergonomics

This feature makes adoption of content-visibility: auto more straightforward, since off-screen element sizing becomes easier to deal with.

Activation

There are no activation risks.

Security

There are no security risks with this feature, since it deals with CSS and Layout sizing.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

This feature uses CSS and is debuggable as any other CSS feature would be.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name on chrome://flags

Finch feature name

CSSContentVisibilityImpliesContainIntrinsicSizeAuto

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1418453

Estimated milestones

Shipping on desktop

117

Shipping on Android

117

Shipping on WebView

117

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5111301323358208

Links to previous Intent discussions

This intent message was generated by Chrome Platform Status.

[Alex Russell]

Please send this as an FYI to the TAG. The fact of something being agreed in the CSS WG does not say much for platform consistency and quality.

Given that I grok this and think it's reasonable (with my ex-TAG member hat on), I'll give y'all a pass on a full review, but please file in future.

LGTM1, contingent on sending an FYI to the TAG.

[Chris Harrelson]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/35983500-d811-476e-aa4a-d726c6308ac8n%40chromium.org.

[Yoav Weiss]

Since this is a behavior change, I'd love to better understand the implications of this change on existing content, and the upper bounds of those implications.

Do we have counters for existing usage that will render differently as a result of this shipping?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9QtaojrgnZy4pY7_2tpF_A1e%3DX0u289VBhAJZ3hg1aqQ%40mail.gmail.com.

[Vladimir Levin]

On Thu, Jul 20, 2023 at 12:08 AM Yoav Weiss <yoav...@chromium.org> wrote:

Since this is a behavior change, I'd love to better understand the implications of this change on existing content, and the upper bounds of those implications.

Do we have counters for existing usage that will render differently as a result of this shipping?

We don't have direct counters for this, no. I think this does impact a good number of sites, just based on the use counters for content-visibility and contain-intrinsic-size.

The type of change is important to consider here: it changes behavior, but in all reasonable cases I can think of, it makes the behavior better. There are less size jumps and scrollbar jitters. This also causes a more stable layout (and indeed was the reason for this proposal on the referenced CSSWG). 

Of course there may be a site that is, for whatever reason, relying on the off-screen size to change. Unfortunately, I don't think we can find out the intent of that site until we launch the feature and hear from developers.

On Wed, Jul 19, 2023 at 6:01 PM Chris Harrelson <chri...@chromium.org> wrote:

LGTM2

On Wed, Jul 19, 2023 at 9:01 AM Alex Russell <sligh...@chromium.org> wrote:

Please send this as an FYI to the TAG. The fact of something being agreed in the CSS WG does not say much for platform consistency and quality.

Given that I grok this and think it's reasonable (with my ex-TAG member hat on), I'll give y'all a pass on a full review, but please file in future.

LGTM1, contingent on sending an FYI to the TAG.

I've filed https://github.com/w3ctag/design-reviews/issues/876

Thanks,

vmpstr

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVquK8te%2BL%2BFNYgwiUeHqzJ5MJL%2BsEVJQ7e_iecVC9Ldg%40mail.gmail.com.

[Yoav Weiss]

LGTM3

On Mon, Jul 24, 2023 at 7:08 PM Vladimir Levin <vmp...@chromium.org> wrote:

On Thu, Jul 20, 2023 at 12:08 AM Yoav Weiss <yoav...@chromium.org> wrote:

Since this is a behavior change, I'd love to better understand the implications of this change on existing content, and the upper bounds of those implications.

Do we have counters for existing usage that will render differently as a result of this shipping?

We don't have direct counters for this, no. I think this does impact a good number of sites, just based on the use counters for content-visibility and contain-intrinsic-size.

The type of change is important to consider here: it changes behavior, but in all reasonable cases I can think of, it makes the behavior better. There are less size jumps and scrollbar jitters. This also causes a more stable layout (and indeed was the reason for this proposal on the referenced CSSWG). 

Of course there may be a site that is, for whatever reason, relying on the off-screen size to change. Unfortunately, I don't think we can find out the intent of that site until we launch the feature and hear from developers.

That makes sense. Please be attentive to developer feedback on this, and have a base flag ready in case we'd need a kill switch.