LGTM2 On Tue, May 14, 2024 at 1:49 PM Mike Taylor <miketa...@chromium.org> wrote:
> From what I can tell, this shipped in Firefox a few days ago, and should > be in 127: https://bugzilla.mozilla.org/show_bug.cgi?id=1281158#c26 > > LGTM1 > On 5/13/24 4:15 PM, 'Daniel Clark' via blink-dev wrote: > > *> Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1281158 > <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> <vmp...@chromium.org> > *Sent:* Monday, May 13, 2024 11:44 AM > *To:* Daniel Clark <dan...@microsoft.com> <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> wrote: > > *Contact emails* > > 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. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW4PR00MB145345C1EC094965340828A8C5E22%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/40f7c922-ade8-4afb-97db-6b7c12cb38e7%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/40f7c922-ade8-4afb-97db-6b7c12cb38e7%40chromium.org?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/CAOMQ%2Bw-4GiVG065thOKgyKdMVoDy%3DcnAvwpZLPq0Nrcu27URPQ%40mail.gmail.com.
