Intent to Ship: CSS advanced attr() function

[Chromestatus]

Contact emails

moo...@google.com, chri...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/css-values-5/#attr-notation

Summary

Implement the augmentation to attr() specified in CSS Level 5, which allows types besides <string> and usage in all CSS properties (besides pseudo-element 'content'). Example: <style> div { background-color: attr(data-foo type(<color>), red); } </style> <div data-foo="blue">test</div>

Blink component

Blink>CSS

Search tags

css, css-values, attr

TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

No browser has implemented this feature yet. Even though there's no negative signals from other browsers, there's still a minimal interoperability risk that we end up the only implementation. There are also a few known cases where this advanced version behaves differently from the basic version in pseudo-element content property, which is a compatibility risk: - https://bit.ly/2XDhHtg - https://bit.ly/3grF3ur

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=435426)

WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=26609)

Web developers: No signals

Other signals:

Security

attr() can be used by injected CSS for data exfiltration. https://github.com/w3c/csswg-drafts/issues/5092

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

No additional DevTools support is needed. attr() function is inspectable in DevTools same way as any other CSS substitution function.

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

Yes

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

Yes

https://wpt.fyi/results/css/css-values?label=master&label=experimental&aligned&q=attr

Flag name on about://flags

CSSAdvancedAttrFunction

Finch feature name

CSSAdvancedAttrFunction

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

Shipping on desktop	133
Shipping on Android	133
Shipping on WebView	133

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/4680129030651904?gate=5932337540366336

This intent message was generated by Chrome Platform Status.

[Patrick Brosset]

"Web developers: No signals" is incorrect, there is a lot of developer interest in this. See this interop 24 focus area proposal for more information: https://github.com/web-platform-tests/interop/issues/521. This Mozilla bug also has 118 votes: https://bugzilla.mozilla.org/show_bug.cgi?id=435426 and this Chromium issue has 125 +1s: https://issues.chromium.org/issues/40320391

[Domenic Denicola]

On Tue, Nov 26, 2024 at 8:07 PM Chromestatus <ad...@cr-status.appspotmail.com> wrote:

Contact emails

moo...@google.com, chri...@chromium.org

Explainer

None

Some sort of explainer would be appreciated for this change, especially given the security complexity.

 

Specification

https://drafts.csswg.org/css-values-5/#attr-notation

Summary

Implement the augmentation to attr() specified in CSS Level 5, which allows types besides <string> and usage in all CSS properties (besides pseudo-element 'content'). Example: <style> div { background-color: attr(data-foo type(<color>), red); } </style> <div data-foo="blue">test</div>

Blink component

Blink>CSS

Search tags

css, css-values, attr

TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

No browser has implemented this feature yet. Even though there's no negative signals from other browsers, there's still a minimal interoperability risk that we end up the only implementation. There are also a few known cases where this advanced version behaves differently from the basic version in pseudo-element content property, which is a compatibility risk: - https://bit.ly/2XDhHtg - https://bit.ly/3grF3ur

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=435426)

WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=26609)

Web developers: No signals

Other signals:

Security

attr() can be used by injected CSS for data exfiltration. https://github.com/w3c/csswg-drafts/issues/5092

How have you resolved these security issues? (A writeup as part of an explainer, perhaps with an alternatives considered section, would help here.)

 

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6745abd8.2b0a0220.19a388.0324.GAE%40google.com.

[Munira Tursunova]

Thank you, Domenic!

I uploaded explainer here: https://github.com/tursunova/web-platform-explainer/blob/main/advanced-attr-explainer.md.

[Domenic Denicola]

Thank you, that explainer is very helpful!

I notice that we're failing all the tests on https://wpt.fyi/results/css/css-values?label=master&label=experimental&aligned&q=attr , probably because this feature is not available behind the experimental-web-platform-features flag.

Can you confirm that we're passing all the tests with the feature-specific flag enabled? Or are there interesting failures left that are worth highlighting?

Regarding compatibility, the scenarios you outlined as changing behavior seem rare enough that I hope they don't cause problems. However, have you made any attempt to quantify them, e.g. via use counter? (It's OK if not.)

Regarding potential open spec issues, I found 6, including two that the TAG highlighted in their review plus one tagged as "Agenda+" implying it's still an active topic for discussion. If you think we don't need to resolve those issues before shipping, can you explain why in more detail?

[Vladimir Levin]

On Mon, Dec 2, 2024 at 10:47 PM Domenic Denicola <dom...@chromium.org> wrote:

Thank you, that explainer is very helpful!

I notice that we're failing all the tests on https://wpt.fyi/results/css/css-values?label=master&label=experimental&aligned&q=attr , probably because this feature is not available behind the experimental-web-platform-features flag.

Can you confirm that we're passing all the tests with the feature-specific flag enabled? Or are there interesting failures left that are worth highlighting?

Regarding compatibility, the scenarios you outlined as changing behavior seem rare enough that I hope they don't cause problems. However, have you made any attempt to quantify them, e.g. via use counter? (It's OK if not.)

The second example (https://github.com/tursunova/web-platform-explainer/blob/main/advanced-attr-explainer.md#example-2 ) seems plausible in that it may be a valid way to organize information on a parent in data attributes and use that in children to display. I have found examples where a similar pattern happens on the element itself (var is set on an element via attr, and then used in element::before's content). I assume that this case will be fine in that the behavior change won't affect it right? I couldn't find any examples of parent to child var transfer (the breaking case), but that of course doesn't mean that it doesn't exist.

Is the plan to roll this out via finch and monitor for breakages?

Thanks,

Vlad

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8-8CgACPS80AmMh2p8kMBW0LtCBrRDARbY%3Di_EWzdfpw%40mail.gmail.com.

[Daniel Bratell]

Beyond what Vlad and Dominic has mentioned, we're also missing formal signals from other vendors. They have requested that we not use generic opinions from staff as official signals. You can find how to get formals vendor signals by following the link "signals on their opinion of the API" in https://www.chromium.org/blink/launching-features/

/Daniel

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NVy6Lvzwz1ifRBm4yfBwYsPO21V3vvAvvQsD2K8b2HaA%40mail.gmail.com.

[Rick Byers]

Discussed in API owners meeting today that we don't really understand the compat risk here. Vlad makes a compelling argument that the risk in example #2 may be non-trivial (especially when considering inheritance scenarios beyond just custom properties). Also you'll need to request enterprise review and they're going to want to know what the extent of the compat risk is (do we need a policy opt-out and 3-release heads up in the release notes?). 

Is there some data you could reasonably collect (UMA and/or a cluster telemetry run perhaps) to try to put an upper bound on the breaking change risk? I think we all expect that the risk is low, but is it extremely low and so something we should just launch with a finch killswitch ready to use at the first sign of issue, or is it only very low meaning we need to go further - especially for our enterprise change guidelines?

Thanks,

   Rick 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7ada5371-84d5-40d8-8a6f-82fc15e9c49c%40gmail.com.

[Munira Tursunova]

Thank you for your replies.

I notice that we're failing all the tests on https://wpt.fyi/results/css/css-values?label=master&label=experimental&aligned&q=attr , probably because this feature is not available behind the experimental-web-platform-features flag.

Can you confirm that we're passing all the tests with the feature-specific flag enabled? Or are there interesting failures left that are worth highlighting?

 Yes, the attr() tests should pass once the runtime flag is enabled.

Regarding potential open spec issues, I found 6, including two that the TAG highlighted in their review plus one tagged as "Agenda+" implying it's still an active topic for discussion. If you think we don't need to resolve those issues before shipping, can you explain why in more detail?

 I have looked at the issues, most of them are not relevant anymore with the new attr() syntax. This also applies to the open issue mentioned in TAG review (issue 5079), I don't think this is relevant anymore since according to CSS Values and Units Module Level 5:

Using an attr()-tainted value as or in a <url> makes a declaration invalid at computed-value time.

There is one issue that might be still relevant (issue 10503), but I don't think it should block the shipping since it's a serialization issue and the spec might already be interpreted that way.

Beyond what Vlad and Dominic has mentioned, we're also missing formal signals from other vendors. They have requested that we not use generic opinions from staff as official signals. You can find how to get formals vendor signals by following the link "signals on their opinion of the API" in https://www.chromium.org/blink/launching-features/

Thanks, filed https://github.com/mozilla/standards-positions/issues/1143 and https://github.com/WebKit/standards-positions/issues/435.

The second example (https://github.com/tursunova/web-platform-explainer/blob/main/advanced-attr-explainer.md#example-2 ) seems plausible in that it may be a valid way to organize information on a parent in data attributes and use that in children to display. I have found examples where a similar pattern happens on the element itself (var is set on an element via attr, and then used in element::before's content). I assume that this case will be fine in that the behavior change won't affect it right? 

Yes, that should work fine, the only dangerous scenarios are when the attr() function is used on the parent element, but the attribute is defined on the child element.

Regarding compatibility, the scenarios you outlined as changing behavior seem rare enough that I hope they don't cause problems. However, have you made any attempt to quantify them, e.g. via use counter? (It's OK if not.)

Is the plan to roll this out via finch and monitor for breakages?

 

Is there some data you could reasonably collect (UMA and/or a cluster telemetry run perhaps) to try to put an upper bound on the breaking change risk? I think we all expect that the risk is low, but is it extremely low and so something we should just launch with a finch killswitch ready to use at the first sign of issue, or is it only very low meaning we need to go further - especially for our enterprise change guidelines?

Manually checked the content of the websites from httparchieve query results, most of the pages use body, attr() and var() on the same pseudo element, which shouldn’t cause the breakages. The upper bound percentage for breakages is ~0.005%. Summed up the analysis for gathered data from httparchieve in the doc.

Thank you,

Munira

[Vladimir Levin]

Thanks for the analysis. 

I think the compat risk here is low. Since we know of at least 3 instances that are likely to break, or at least to have a different behavior, I'd ask that we try to reach out to those sites as an FYI about this change.

Other than that, LGTM1

[Mike Taylor]

+1 to Vladimir's recommendation here. LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MN2s83Vg2qjKy%2BpfVBRmbgY8UKsmXnAK3TkcgsPA_bhg%40mail.gmail.com.

[Rick Byers]

3 potential sites in the 12 M for something almost certainly minor/superficial UI breakage indeed seems exceedingly low risk to me. 

LGTM3 to ship. But as always, if you get reports of breakage prior to hitting stable, please use the kill-switch and circle back here for a more thorough compat analysis discussion.

Rick