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 On Wed, Dec 11, 2024 at 4:01 PM Mike Taylor <miketa...@chromium.org> wrote: > +1 to Vladimir's recommendation here. LGTM2 > On 12/11/24 4:00 PM, Vladimir Levin wrote: > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MN2s83Vg2qjKy%2BpfVBRmbgY8UKsmXnAK3TkcgsPA_bhg%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/CAFUtAY-va%3DS%2BZ6OxN3dcW328vNzQjdR0q5F7V-hVU_3ivfQxAA%40mail.gmail.com.
