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//)/

/> 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> wrote:

    *Contact emails*

    dan...@microsoft.com

    *Explainer*

    None

    *Specification*

    
https://drafts.csswg.org/css-content-3/#valdef-content---string--counter--attrand
    https://drafts.csswg.org/css-content-3/#alt
    <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
    
<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.

Reply via email to