> Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1281158) > It's hard to parse the sentiment in that bug, but it doesn't seem negative at > least :) I don't know if it's worth filing a position request
Since I last looked at this bug, Gecko has actually started implementing the feature: https://hg.mozilla.org/mozilla-central/rev/df46563babe2. Based on this comment<https://hg.mozilla.org/mozilla-central/rev/df46563babe2#l13.37> they’re also excluding counter(), so they’ll match the behavior I’m proposing to ship here. Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1896047 the work isn’t quite finished yet. So based on these updates I think it’s fair to say that the Gecko position is actually “In Development” rather than “No Signal”. > I believe this is behind the CSSContentMultiArgAltText flag, right? That’s right. -- Dan From: Vladimir Levin <vmp...@chromium.org> Sent: Monday, May 13, 2024 11:44 AM To: Daniel Clark <dan...@microsoft.com> Cc: blink-dev@chromium.org Subject: Re: [blink-dev] Intent to Ship: Multi-argument alt text in CSS Generated Content On Mon, May 13, 2024 at 2:23 PM 'Daniel Clark' via blink-dev <blink-dev@chromium.org<mailto:blink-dev@chromium.org>> wrote: Contact emails dan...@microsoft.com<mailto:dan...@microsoft.com> Explainer None Specification https://drafts.csswg.org/css-content-3/#valdef-content---string--counter--attr and https://drafts.csswg.org/css-content-3/#alt Summary The CSS content property allows developers to specify alternative text for accessibility with the following syntax: .has-before-content::before { content: url("cat.jpg") / "A cute cat"; } This functionality, where the alt text is given by a single string, is already supported in Chromium (https://chromestatus.com/feature/4550056227110912). However, the spec allows the alt text to be given by an arbitrary number of elements, which in addition to strings can be attr() functions or counters. For example: .has-before-content::before { content: url("cat.jpg") / "A cute " attr(data-animal); } This Intent tracks the expansion of the Chromium implementation to support an arbitrary number of arguments as well as attr() functions in addition to strings. Note that this Intent to Ship does *not* include the addition of counter support. This turns out to add significant complexity since counters are normally evaluated as part of layout tree computation and the alt text being evaluated does not participate in the layout tree. The existing WebKit implementation of this feature does not support counters<https://github.com/WebKit/WebKit/blob/c1c858cf081e67326c44328c12ab5ddb53a8799b/Source/WebCore/css/parser/CSSPropertyParserHelpers.cpp#L3675>, so by shipping what’s proposed here Chromium will align with WebKit. Blink component Blink>Accessibility<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EAccessibility> TAG review https://github.com/w3ctag/design-reviews/issues/351 TAG review status Issues Addressed Risks Interoperability and Compatibility The new syntax will fail to parse in browser where it’s not supported, so until browser support is widespread, developers should include a preceding fallback line to specify the content: .has-before-content::before { content: url("cat.jpg"); /* Used if the following line doesn't parse */ content: url("cat.jpg") / "A cute " attr(data-animal); } This compat risk is not really new given the feature’s current state of partial support. The lack of counter support in this implementation means there will still be a gap between what we’re planning to ship here and the spec. However since Chromium already ships a partial implementation, and the updated implementation supports more of the spec and puts us into alignment with WebKit, shipping this puts things in a strictly better position. Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1281158) It's hard to parse the sentiment in that bug, but it doesn't seem negative at least :) I don't know if it's worth filing a position request WebKit: Shipped/Shipping (https://github.com/WebKit/WebKit/pull/22185) Web developers: There have been several blog posts ([1]<https://www.sitelint.com/blog/alternative-text-for-css-generated-content>, [2]<https://adrianroselli.com/2020/10/alternative-text-for-css-generated-content.html>, [3]<https://www.stefanjudis.com/today-i-learned/css-content-accepts-alternative-text/#edits-part-1-%E2%80%93-define-the-alternative-text-in-html-or-custom-properties>, [4]<https://johnkavanagh.co.uk/articles/alternative-text-in-the-css-content-property/>) and a StackOverflow answer<https://stackoverflow.com/questions/5943223/put-title-alt-attributes-into-css-after-content-image> written about the feature, with positive sentiment. Other signals: This functionality is tested as part of the Interop2024 Accessibility focus area. Specifically, https://wpt.fyi/results/accname/name/comp_name_from_content.html?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-accessibility sub-tests "(button|heading|link) name from fallback content mixing attr() and strings with ::before and ::after" 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? No Debuggability The accessible text can be viewed in the accessibility tree via chrome://accessibility. DevTools allows this part of the content property to be edited in the Style pane. 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>? https://wpt.fyi/results/css/css-content/parsing/content-valid.html https://wpt.fyi/results/accname/name/comp_name_from_content.html (sub-tests "(button|heading|link) name from fallback content mixing attr() and strings with ::before and ::after") Flag name on chrome://flags None Finch feature name None I believe this is behind the CSSContentMultiArgAltText flag, right? Non-finch justification None Requires code in //chrome? False Availability expectation Already implemented in WebKit. Mozilla bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1281158. Estimated milestones 127 Anticipated spec changes None Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5168344402755584 Links to previous Intent discussions Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW4PR00MB1455CC35408799CAF44F732CC5162%40MW4PR00MB1455.namprd00.prod.outlook.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<mailto:blink-dev+unsubscr...@chromium.org>. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW4PR00MB145308E8191DB68C9F67C9BEC5E22%40MW4PR00MB1453.namprd00.prod.outlook.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW4PR00MB145308E8191DB68C9F67C9BEC5E22%40MW4PR00MB1453.namprd00.prod.outlook.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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW4PR00MB145345C1EC094965340828A8C5E22%40MW4PR00MB1453.namprd00.prod.outlook.com.
