Intent to Ship: Disable propagation of body style to viewport when contained

[Rune Lillesveen]

Contact emails

fut...@chromium.org

Specification

http://drafts.csswg.org/css-contain-1/#c3

Summary

Used values for contain different from none on the root or body elements will disable propagation of CSS properties from body as per specification[1]. [1] https://drafts.csswg.org/css-contain-1/#c3

This change was brought to the CSSWG because the unconditionally propagating body styles to the viewport would create circular dependencies for CSS Container Queries. For instance, a propagated writing-mode from body to the viewport, when orthogonal to the outer, could change the size of root element which in turn could affect style resolution for body via container queries, which again could result in a different computed writing-mode for body. See the github issue for details: https://github.com/w3c/csswg-drafts/issues/5913. It should be noted that the CSSWG has regretted introducing propagation from body and have resolved on not introducing new properties to be propagated from body.

The implementation was added to M93 behind a flag along with use counters for used contain values different from none on html root and body:

https://chromestatus.com/metrics/feature/timeline/popularity/3936

https://chromestatus.com/metrics/feature/timeline/popularity/3937

These use counters cover more cases than potentially problematic ones, as they do not detect if the styles are different on body and root and would make any differences. Still the use counters are low - 0.0004% and 0.0008% respectively.

Blink component

Blink>CSS

TAG review

None. Change to a W3C Recommendation in the CSSWG.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

• Not shipping this change would block shipping CSS Container Queries, or cause stateful style/layout issues.
• Low use counters for containment on body and root.
• There is an interop risk if the other engines do not change their implementations. The use counters indicate that, at least at the moment, applying containment to root and body is rare.

I have not filed a standards position for Gecko. This seems like a rather small change compared to APIs typically filed as a standards position. I got a quick reply on the webkit-thread.

Issues are filed for both browsers and I have triaged the failing tests on wpt.fyi accordingly.

Gecko: No signals https://bugzilla.mozilla.org/show_bug.cgi?id=1730763

WebKit: No objection: https://lists.webkit.org/pipermail/webkit-dev/2021-September/031982.html

Web developers: No signals

Debuggability

Viewport propagated properties are not exposed in devtools

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

contain-body-bg-001.html
contain-body-bg-002.html
contain-body-bg-003.html
contain-body-bg-004.html
contain-body-dir-001.html
contain-body-dir-002.html
contain-body-dir-003.html
contain-body-dir-004.html
contain-body-overflow-001.html
contain-body-overflow-002.html
contain-body-overflow-003.html
contain-body-overflow-004.html
contain-body-t-o-001.html
contain-body-t-o-002.html
contain-body-t-o-003.html
contain-body-t-o-004.html
contain-body-w-m-001.html
contain-body-w-m-002.html
contain-body-w-m-003.html
contain-body-w-m-004.html
contain-html-bg-001.html
contain-html-bg-002.html
contain-html-bg-003.html
contain-html-bg-004.html
contain-html-dir-001.html
contain-html-dir-002.html
contain-html-dir-003.html
contain-html-dir-004.html
contain-html-overflow-001.html
contain-html-overflow-002.html
contain-html-overflow-003.html
contain-html-overflow-004.html
contain-html-t-o-001.html
contain-html-t-o-002.html
contain-html-t-o-003.html
contain-html-t-o-004.html
contain-html-w-m-001.html
contain-html-w-m-002.html
contain-html-w-m-003.html
contain-html-w-m-004.html

Flag name

CSSContainedBodyPropagation

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1215265

Estimated milestones

M96

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5663240823504896

This intent message was generated by Chrome Platform Status.

--

Rune Lillesveen

[Mike Taylor]

Hey Rune,

Is there any way for developers to know behavior has changed on their sites when this ships? (Or alternatively, any clues for folks triaging bugs, besides bisecting?).

I'm wondering about sites where breakage is pretty bad. Would it be useful to ship a devtools issue (probably overkill given the use counter data, especially if they're over-counting problematic cases...)?

(Also, I asked dholbert if he thinks it's something Gecko would want to ship in https://bugzilla.mozilla.org/show_bug.cgi?id=1730763#c2)

[Manuel Rego Casasnovas]

LGTM1.

Given the positive replies from Firefox and WebKit and the small use
counters I believe it's fine doing this change.

Cheers,
Rego

On 15/09/2021 14:55, Mike Taylor wrote:
> Hey Rune,
>
> Is there any way for developers to know behavior has changed on their
> sites when this ships? (Or alternatively, any clues for folks triaging
> bugs, besides bisecting?).
>
> I'm wondering about sites where breakage is pretty bad. Would it be
> useful to ship a devtools issue (probably overkill given the use counter
> data, especially if they're over-counting problematic cases...)?
>
> (Also, I asked dholbert if he thinks it's something Gecko would want to
> ship in https://bugzilla.mozilla.org/show_bug.cgi?id=1730763#c2)
>
>
> On 9/14/21 6:12 PM, Rune Lillesveen wrote:
>>
>>
>> Contact emails
>>

>> fut...@chromium.org <mailto:fut...@chromium.org>
>>
>>
>> Specification
>>
>> http://drafts.csswg.org/css-contain-1/#c3

>> <http://drafts.csswg.org/css-contain-1/#c3>
>>
>>
>> Summary
>>
>> Used values for contain different from none on the root or body
>> elements will disable propagation of CSS properties from body as per
>> specification[1]. [1] https://drafts.csswg.org/css-contain-1/#c3
>> <https://drafts.csswg.org/css-contain-1/#c3>
>>
>>
>> This change was brought to the CSSWG because the unconditionally
>> propagating body styles to the viewport would create circular
>> dependencies for CSS Container Queries. For instance, a propagated
>> writing-mode from body to the viewport, when orthogonal to the outer,
>> could change the size of root element which in turn could affect style
>> resolution for body via container queries, which again could result in
>> a different computed writing-mode for body. See the github issue for
>> details: https://github.com/w3c/csswg-drafts/issues/5913

>> <https://github.com/w3c/csswg-drafts/issues/5913>. It should be noted

>> that the CSSWG has regretted introducing propagation from body and
>> have resolved

>> <https://github.com/w3c/csswg-drafts/issues/6079#issuecomment-816307011>

>> on not introducing new properties to be propagated from body.
>>
>> The implementation was added to M93 behind a flag along with use
>> counters for used contain values different from none on html root and
>> body:
>>
>> https://chromestatus.com/metrics/feature/timeline/popularity/3936

>> <https://chromestatus.com/metrics/feature/timeline/popularity/3936>
>> https://chromestatus.com/metrics/feature/timeline/popularity/3937

>> <https://chromestatus.com/metrics/feature/timeline/popularity/3937>
>>
>> These use counters cover more cases than potentially problematic ones,
>> as they do not detect if the styles are different on body and root and
>> would make any differences. Still the use counters are low - 0.0004%
>> and 0.0008% respectively.
>>
>>
>> Blink component
>>
>> Blink>CSS

>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>

>>
>>
>> TAG review
>>
>> None. Change to a W3C Recommendation in the CSSWG.
>>
>>
>> TAG review status
>>
>> Not applicable
>>
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>

>> * Not shipping this change would block shipping CSS Container

>> Queries, or cause stateful style/layout issues.

>> * Low use counters for containment on body and root.
>> * There is an interop risk if the other engines do not change their

>> implementations. The use counters indicate that, at least at the
>> moment, applying containment to root and body is rare.
>>
>> I have not filed a standards position for Gecko. This seems like a
>> rather small change compared to APIs typically filed as a
>> standards position. I got a quick reply on the webkit-thread.
>> Issues are filed for both browsers and I have triaged the failing
>> tests on wpt.fyi accordingly.
>>
>> Gecko: No signals https://bugzilla.mozilla.org/show_bug.cgi?id=1730763
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1730763>
>>
>> WebKit: No
>> objection: https://lists.webkit.org/pipermail/webkit-dev/2021-September/031982.html
>> <https://lists.webkit.org/pipermail/webkit-dev/2021-September/031982.html>
>>
>> Web developers: No signals
>

> --
> 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
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f2eb218d-29ac-c82b-6620-ccc81b9be5ed%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f2eb218d-29ac-c82b-6620-ccc81b9be5ed%40chromium.org?utm_medium=email&utm_source=footer>.

[Rune Lillesveen]

On Wed, Sep 15, 2021 at 2:55 PM Mike Taylor <mike...@chromium.org> wrote:

Hey Rune,

Is there any way for developers to know behavior has changed on their sites when this ships? (Or alternatively, any clues for folks triaging bugs, besides bisecting?).

I'm wondering about sites where breakage is pretty bad. Would it be useful to ship a devtools issue (probably overkill given the use counter data, especially if they're over-counting problematic cases...)?

You mean adding a devtools warning if the propagated values would have been different without containment?

I think the background and overflow scrollbar propagation would have pretty obvious effects. If the body direction/writing-mode is orthogonal to the root html direction/writing-mode, such effects would be more subtle and harder to spot. We have changed how body/html/viewport propagation for orthogonal writing-modes have been done before without any such signals/warnings (not sure if we even have done intent-to-ship for that).

(Also, I asked dholbert if he thinks it's something Gecko would want to ship in https://bugzilla.mozilla.org/show_bug.cgi?id=1730763#c2)

Thanks! Positive response from dholbert.

--

Rune Lillesveen

[Mike West]

LGTM2.

I agree with Mike Taylor that we should generally be giving developers insight into changes via devtools when practical, and helping them through shifts in behavior so they're not surprised. That said, for this particular change, I agree with Rego that the risk is quite low, and assuming Firefox will follow along, developers will quickly regain a consistent story.

Please keep an eye on feedback through dev and beta channels, but I'm comfortable with y'all trying this change.

-mike

--
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/CACuPfeSk22%3D%2Bn%3DSuG%2BK8p%2BYKA%3DLE4AoZ7516LkddzARZp7_yhA%40mail.gmail.com.

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3De43pQBXdxbi%2BjjdTfO2SeH1%3Dieqvw8fkaSDXdoUR-8Vw%40mail.gmail.com.

[Mike Taylor]

On Wednesday, September 15, 2021 at 4:23:13 PM UTC-4 Rune Lillesveen wrote:

On Wed, Sep 15, 2021 at 2:55 PM Mike Taylor <mike...@chromium.org> wrote:

Hey Rune,

Is there any way for developers to know behavior has changed on their sites when this ships? (Or alternatively, any clues for folks triaging bugs, besides bisecting?).

I'm wondering about sites where breakage is pretty bad. Would it be useful to ship a devtools issue (probably overkill given the use counter data, especially if they're over-counting problematic cases...)?

You mean adding a devtools warning if the propagated values would have been different without containment?

Yeah, I'm mostly thinking out loud here trying to wear a front-end developer hat (it's an old hat, the last time I wrote any serious CSS `contain` didn't exist in browsers) - would I know how to debug any observable effects after these changes land? But I recognize there's a non-zero cost to adding messaging to devtools like this, and the use-counter data shows potential side-effects will be rare.