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
[email protected] <mailto:[email protected]>
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 [email protected].
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.
