Intent to Ship: Add containerName and containerQuery, update conditionText

[Daniil Sakhapov]

Contact emails

sakh...@chromium.org

Specification

https://w3c.github.io/csswg-drafts/css-contain-3/#the-csscontainerrule-interface

Summary

Updates the CSSContainerRule interface to match the specs. Implements containerName and containerQuery, updates conditionText for @container to be up-to-date with specs.

Blink component

Blink>CSS

TAG review

https://github.com/w3ctag/design-reviews/issues/592

TAG review status

Issues addressed

Risks

Activation

Previous conditionText attribute contained only container-query part, but now it's both container-name and container-query. But it should not break a lot of sites due to low current usage as per: https://chromestatus.com/metrics/css/timeline/popularity/697 https://chromestatus.com/metrics/css/timeline/popularity/699 The real breakage is hard to measure, as it's not possible to track the how result of conditionText is used and the usage of container-name is low compared to the container-type usage. Also, conditionText is readonly, so there are no round-trip issues

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

https://wpt.fyi/css/css-contain/container-queries/at-container-style-serialization.html
https://wpt.fyi/css/css-contain/container-queries/at-container-serialization.html
https://wpt.fyi/css/css-contain/container-queries/idlharness.html
https://wpt.fyi/css/cssom/CSSContainerRule.tentative.html

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1393577

Estimated milestones

DevTrial on desktop

112

DevTrial on Android

112

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5159369837117440

This intent message was generated by Chrome Platform Status.

[Alex Russell]

Hey Daniil:

Thanks for filing for this change while the feature is still low-use; it'll be much more challenging to make this switch later.

Something that wasn't clear from the use counters you linked was the use of the IDL properties vs. the CSS names. Given that it seems like we have use-counters for the latter but not the former, it seems reasonable to consider CSS usage to be a hard cap on potential use of the JS interface.

Would you be willing to manually inspect some content (say 10-20 sites) that use the CSS `container-name` and `container-query` attributes to look for script access? Presumably it's a fraction that population, but verifying would be helpful.

Thanks

[Daniil Sakhapov]

Hi!

So, I haven't found any usage on the websites chromestatus gave me.

But looking at WebArchive results I can see that the usage is very small and the update won't change anything.

[Daniil Sakhapov]

And another query for @container + conditionText. There are no things that can be broken.

https://docs.google.com/spreadsheets/d/1ILyBkGLud7fy4kXjlLURELhcMRAPqdEWz8X8J25SfDY/edit?usp=sharing

[Philip Jägenstedt]

LGTM1

Thanks Daniil for that httparchive analysis. The second one looking for use of the @container rule should include all cases that could matter. 56 unique matches is a very small number when it comes to httparchive compat analysis. I double checked just one of them (botaniska.se, a nice park in Gothenburg!) and indeed that usage doesn't even involve CSSContainerRule. When we're unable to find even a single case that would break, that's as good as it gets for compat risk.

Let's ship it before something starts to depend on the old behavior!

--
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/CAH3Z92_u4JkFfr4KE-z_Xyt9x_T3Jks40xiEs5vNjcwBsurjjQ%40mail.gmail.com.

[Mike Taylor]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeVAsLcvqfkch2ikF%2Bn-XY-J-NNeEvPs3aNfajtv%2B-uJw%40mail.gmail.com.

[Rick Byers]

Looks to be a very low risk update to a brand new feature, LGTM3

But what do we know about the other implementations with respect to this change? For any which haven't yet updated, are there bugs tracking it?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/383df41b-f40a-bad7-15e3-0fdddf51663e%40chromium.org.

[Daniil Sakhapov]

Hi, Rick!

Thanks! Not sure I understand what you mean.

[Rick Byers]

Sorry I wasn't clear. I mean that WebKit and Gecko have implementations of container queries, do they already support these properties? If not, we want to ensure they're aware of the spec change and have open bugs tracking making updates to their engines to reduce the likely time period for inconsistent behavior between browsers especially since there's some web compat risk around conditionText.

In general we're looking for signals from the other engines. This is what the Safari and Firefox signals portion of the status entry are for, but yours are both blank. In this case it's a tiny change approved by the CSSWG so I'm not too worried (hence my LGTM without blocking), but the principle of evolving the web together with the other engines still applies.

Thanks,

   Rick

[Daniil Sakhapov]

Now I see, thanks!

Firefox has updated their implementation and is up-to-date.

Safari hasn't done anything yet from what I can tell. I will ping them.

Long live the web platform!

[Rick Byers]

Thanks Danil. Great, that means you can mark 'Firefox' as 'shipping' in chromestatus. For Safari ideally you'd link to a WebKit bug tracking this, but regardless (even if they say something positive) the signal stays as "no signal" (unless they too are shipping or have an official standards position entry - which seems like overkill here). 

Rick