Intent to Prototype and Ship: contain-intrinsic-size: auto none support

[Vladimir Levin]

Contact emails

vmp...@chromium.org

Specification

None

Summary

This feature extends the existing contain-intrinsic-size syntax: none | <length> | auto && <length> to also include auto && none: none | <length> | auto && <length> | auto && none The reason for this change is the CSSWG resolution (https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1440466558) to add an interaction between content-visibility: auto and contain-intrinsic-size. Specifically, that the former adds an "auto" keyword to the latter. For this to work, the resolution includes a note to extend contain-intrinsic-size syntax for "auto" to work with all existing keywords, including "none".

Blink component

Blink>CSS

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There is a risk of interoperability since the new syntax would previously be considered invalid, and result in a default behavior (equivalent to contain-intrinsic-size: none). Sites currently specifying contain-intrinsic-size: auto none would have their behavior change on Chromium after this feature launches.

I estimate this risk to be low.

Gecko: No signal This change was discussed in CSSWG and there were no objections to the resolutions

WebKit: No signal This change was discussed in CSSWG and there were no objections to the resolutions

Web developers: No signals

Other signals:

Ergonomics

None. This is an improvement which will allow future work to improve ergonomics of content-visibility.

Activation

None.

Security

None.

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 is debuggable in the same way as other CSS features.

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

CSSContainIntrinsicSizeAutoNone

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

M116

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/6203168806928384

Links to previous Intent discussions

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Fri, Jun 9, 2023 at 10:19 PM 'Vladimir Levin' via blink-dev <blin...@chromium.org> wrote:

Contact emails

vmp...@chromium.org

Specification

None

Summary

This feature extends the existing contain-intrinsic-size syntax: none | <length> | auto && <length> to also include auto && none: none | <length> | auto && <length> | auto && none The reason for this change is the CSSWG resolution (https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1440466558) to add an interaction between content-visibility: auto and contain-intrinsic-size. Specifically, that the former adds an "auto" keyword to the latter. For this to work, the resolution includes a note to extend contain-intrinsic-size syntax for "auto" to work with all existing keywords, including "none".

Blink component

Blink>CSS

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There is a risk of interoperability since the new syntax would previously be considered invalid, and result in a default behavior (equivalent to contain-intrinsic-size: none). Sites currently specifying contain-intrinsic-size: auto none would have their behavior change on Chromium after this feature launches.

I estimate this risk to be low.

Would you be able to confirm that estimate e.g. with an HTTP archive search?

Gecko: No signal This change was discussed in CSSWG and there were no objections to the resolutions

WebKit: No signal This change was discussed in CSSWG and there were no objections to the resolutions

Can you please file signals? I don't believe a CSSWG counts as a positive signal. Also, I don't believe I saw a comment from any WebKit person on the minutes.

A signal request would let them know this is being worked on in Chromium.

  

--
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/CADsXd2MgWYdmrJ1JHv0rYTWr2wcqUQ%2BZUriH5UQAREw7Wg0Ptg%40mail.gmail.com.

[Vladimir Levin]

Thank you for your feedback. My responses are inline below

On Wed, Jun 14, 2023 at 12:24 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Jun 9, 2023 at 10:19 PM 'Vladimir Levin' via blink-dev <blin...@chromium.org> wrote:

Contact emails

vmp...@chromium.org

Specification

None

Summary

This feature extends the existing contain-intrinsic-size syntax: none | <length> | auto && <length> to also include auto && none: none | <length> | auto && <length> | auto && none The reason for this change is the CSSWG resolution (https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1440466558) to add an interaction between content-visibility: auto and contain-intrinsic-size. Specifically, that the former adds an "auto" keyword to the latter. For this to work, the resolution includes a note to extend contain-intrinsic-size syntax for "auto" to work with all existing keywords, including "none".

Blink component

Blink>CSS

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There is a risk of interoperability since the new syntax would previously be considered invalid, and result in a default behavior (equivalent to contain-intrinsic-size: none). Sites currently specifying contain-intrinsic-size: auto none would have their behavior change on Chromium after this feature launches.

I estimate this risk to be low.

Would you be able to confirm that estimate e.g. with an HTTP archive search?

I'm in the process of figuring out how to do this, and will get back to you with the results when I have them. My estimate stems from the fact that currently "contain-intrinsic-size: auto none" is considered an invalid syntax, making it unlikely to be used as a value.

 

Gecko: No signal This change was discussed in CSSWG and there were no objections to the resolutions

WebKit: No signal This change was discussed in CSSWG and there were no objections to the resolutions

Can you please file signals? I don't believe a CSSWG counts as a positive signal. Also, I don't believe I saw a comment from any WebKit person on the minutes.

A signal request would let them know this is being worked on in Chromium.

I have filed the following requests for positions:

Mozilla: https://github.com/mozilla/standards-positions/issues/827 

WebKit: https://github.com/WebKit/standards-positions/issues/205

I've updated the chrome status entry page with this information.

Thanks,

vmpstr

[Vladimir Levin]

On Fri, Jun 16, 2023 at 1:12 PM Vladimir Levin <vmp...@google.com> wrote:

Thank you for your feedback. My responses are inline below

On Wed, Jun 14, 2023 at 12:24 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Jun 9, 2023 at 10:19 PM 'Vladimir Levin' via blink-dev <blin...@chromium.org> wrote:

Contact emails

vmp...@chromium.org

Specification

None

Summary

This feature extends the existing contain-intrinsic-size syntax: none | <length> | auto && <length> to also include auto && none: none | <length> | auto && <length> | auto && none The reason for this change is the CSSWG resolution (https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1440466558) to add an interaction between content-visibility: auto and contain-intrinsic-size. Specifically, that the former adds an "auto" keyword to the latter. For this to work, the resolution includes a note to extend contain-intrinsic-size syntax for "auto" to work with all existing keywords, including "none".

Blink component

Blink>CSS

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There is a risk of interoperability since the new syntax would previously be considered invalid, and result in a default behavior (equivalent to contain-intrinsic-size: none). Sites currently specifying contain-intrinsic-size: auto none would have their behavior change on Chromium after this feature launches.

I estimate this risk to be low.

Would you be able to confirm that estimate e.g. with an HTTP archive search?

I'm in the process of figuring out how to do this, and will get back to you with the results when I have them. My estimate stems from the fact that currently "contain-intrinsic-size: auto none" is considered an invalid syntax, making it unlikely to be used as a value.

Based on my http archive queries that use regular expression to match particular values of contain-intrinsic-[a-z-]* (size, width, height, block-size, inline-size), out of all of the contain-intrinsic-* values, about half of them (50%) have an 'auto' keyword that follows the semicolon and possibly whitespace. However, 0 of those have "auto[ ]*none" in them.

As a disclaimer, the total amount of contain-intrinsic-* pages I got using these queries is substantially smaller than the use counter data would indicate. I presume this is due to limitations such as case sensitivity, script constructing these values, etc, but I'm not sure.

This seems to confirm my estimate of low risk in enabling this by default. Let me know if you agree, or whether you'd like me to do more research.

Thanks in advance,

vmpstr

[Yoav Weiss]

Thanks for confirming that!!

 

Thanks in advance,

vmpstr

 

Gecko: No signal This change was discussed in CSSWG and there were no objections to the resolutions

WebKit: No signal This change was discussed in CSSWG and there were no objections to the resolutions

Can you please file signals? I don't believe a CSSWG counts as a positive signal. Also, I don't believe I saw a comment from any WebKit person on the minutes.

A signal request would let them know this is being worked on in Chromium.

I have filed the following requests for positions:

Mozilla: https://github.com/mozilla/standards-positions/issues/827 

WebKit: https://github.com/WebKit/standards-positions/issues/205

Both positions indicate there are open spec questions. Can you expand on those and their future compat/interop risk?

[Vladimir Levin]

Mozilla's comment (needs a spec) is being address in the following PR: https://github.com/w3c/csswg-drafts/pull/8989

WebKit's comment about an open question seems to refer to discussion that follows the resolution with one question from Emilio: https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1496753402. This question relates to a different part of the resolution (content-visibility: auto "upgrading" contain-intrinsic-size to have an auto keyword).

I've added a comment to both position requests.

Thanks,

vmpstr

[Vladimir Levin]

I've added a blurb about this in the compat/interop risk section.

[slightlyoff via Chromestatus]

Excited to see this land; LGTM1

[Daniel Bratell]

LGTM2

/Daniel

On 2023-07-05 17:39, slightlyoff via Chromestatus wrote:

Excited to see this land; LGTM1

--
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/000000000000138e3105ffbf36a9%40google.com.

[Mike Taylor]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/96e668ee-ced2-e88d-a534-87f3d5b32f49%40gmail.com.