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 > <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 >>> , 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 >>>>>> >>>>>> >>>>>> 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/CAAO7W_B1DRyHofn2bir3vCS0FdgowyENJE%2BMrjgk0_75-wrV9g%40mail.gmail.com.
