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>
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
attr() can be used by injected CSS for data exfiltration. https://github.com/w3c/csswg-drafts/issues/5092
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
No additional DevTools support is needed. attr() function is inspectable in DevTools same way as any other CSS substitution function.
https://wpt.fyi/results/css/css-values?label=master&label=experimental&aligned&q=attr
Shipping on desktop | 133 |
Shipping on Android | 133 |
Shipping on WebView | 133 |
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).
NoneContact emails
moo...@google.com, chri...@chromium.orgExplainer
None
Specification
https://drafts.csswg.org/css-values-5/#attr-notationSummary
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>CSSSearch tags
css, css-values, attrTAG review
https://github.com/w3ctag/design-reviews/issues/513TAG review status
PendingRisks
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
--
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.
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.)
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/7ada5371-84d5-40d8-8a6f-82fc15e9c49c%40gmail.com.
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 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?
Using an attr()-tainted value as or in a <url> makes a declaration invalid at computed-value time.
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/
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?
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?
+1 to Vladimir's recommendation here. LGTM2