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 >> , >> 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/CADsXd2MN2s83Vg2qjKy%2BpfVBRmbgY8UKsmXnAK3TkcgsPA_bhg%40mail.gmail.com.
