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
On Wed, Dec 11, 2024 at 12:42 PM Munira Tursunova <moon...@google.com>
wrote:
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
<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
<https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+label%3Acss-values-5+attr+in%3Atitle>,
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
<https://github.com/w3c/csswg-drafts/issues/5079>), I don't think
this is relevant anymore since according to CSS Values and Units
Module Level 5: <https://drafts.csswg.org/css-values-5/#attr-security>
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
<https://github.com/w3c/csswg-drafts/issues/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
<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
<https://github.com/tursunova/web-platform-explainer/blob/main/advanced-attr-explainer.md#backwards-compatibility>
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
<https://www.chromium.org/developers/enterprise-changes/>?
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
<https://docs.google.com/document/d/15pi0QVsZkOIbxDY6p8tH5v1E-UabMC8aR4YXfYb9C1Q/edit?usp=sharing>.
Thank you,
Munira
On Wed, Dec 4, 2024 at 5:41 PM Rick Byers <rby...@chromium.org> wrote:
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
<https://www.chromium.org/developers/enterprise-changes/>?
Thanks,
Rick
On Wed, Dec 4, 2024 at 9:43 AM Daniel Bratell
<bratel...@gmail.com> wrote:
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
On 2024-12-04 03:29, Vladimir Levin wrote:
On Mon, Dec 2, 2024 at 10:47 PM Domenic Denicola
<dome...@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
<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
<https://github.com/tursunova/web-platform-explainer/blob/main/advanced-attr-explainer.md#backwards-compatibility>
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
Regarding potential open spec issues, I found 6
<https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+label%3Acss-values-5+attr+in%3Atitle>,
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?
On Tue, Dec 3, 2024 at 12:31 AM Munira Tursunova
<moon...@google.com> wrote:
Thank you, Domenic!
I uploaded explainer here:
https://github.com/tursunova/web-platform-explainer/blob/main/advanced-attr-explainer.md.
On Wed, Nov 27, 2024 at 3:02 AM Domenic Denicola
<dome...@chromium.org> wrote:
On Tue, Nov 26, 2024 at 8:07 PM Chromestatus
<ad...@cr-status.appspotmail.com> wrote:
Contact emails
moon...@google.com, chris...@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
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
Search tags
css <http:///features#tags:css>,
css-values
<http:///features#tags:css-values>, attr
<http:///features#tags: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.)
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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes
https://wpt.fyi/results/css/css-values?label=master&label=experimental&aligned&q=attr
<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
<https://chromestatus.com>.
--
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+unsubscr...@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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6745abd8.2b0a0220.19a388.0324.GAE%40google.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8-8CgACPS80AmMh2p8kMBW0LtCBrRDARbY%3Di_EWzdfpw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8-8CgACPS80AmMh2p8kMBW0LtCBrRDARbY%3Di_EWzdfpw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NVy6Lvzwz1ifRBm4yfBwYsPO21V3vvAvvQsD2K8b2HaA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NVy6Lvzwz1ifRBm4yfBwYsPO21V3vvAvvQsD2K8b2HaA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7ada5371-84d5-40d8-8a6f-82fc15e9c49c%40gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7ada5371-84d5-40d8-8a6f-82fc15e9c49c%40gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MN2s83Vg2qjKy%2BpfVBRmbgY8UKsmXnAK3TkcgsPA_bhg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MN2s83Vg2qjKy%2BpfVBRmbgY8UKsmXnAK3TkcgsPA_bhg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
