Intent to Ship: Multi-argument alt text in CSS Generated Content

567 views
Skip to first unread message

Daniel Clark

unread,
May 13, 2024, 2:23:15 PMMay 13
to blin...@chromium.org

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, so by shipping what’s proposed here Chromium will align with WebKit.

Blink component

Blink>Accessibility

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)

WebKit: Shipped/Shipping (https://github.com/WebKit/WebKit/pull/22185)

Web developers: There have been several blog posts ([1], [2], [3], [4]) and a StackOverflow answer 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://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

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

 

Vladimir Levin

unread,
May 13, 2024, 2:44:19 PMMay 13
to Daniel Clark, blin...@chromium.org
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], [2], [3], [4]) and a StackOverflow answer 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://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+...@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.

Daniel Clark

unread,
May 13, 2024, 4:15:16 PMMay 13
to Vladimir Levin, blin...@chromium.org

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

Mike Taylor

unread,
May 14, 2024, 4:49:52 PMMay 14
to Daniel Clark, Vladimir Levin, blin...@chromium.org

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

Chris Harrelson

unread,
May 14, 2024, 5:01:17 PMMay 14
to Mike Taylor, Daniel Clark, Vladimir Levin, blin...@chromium.org
LGTM2

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.

Domenic Denicola

unread,
May 15, 2024, 1:41:36 AMMay 15
to blink-dev, Chris Harrelson, dan...@microsoft.com, Vladimir Levin, blin...@chromium.org, Mike Taylor
LGTM3.

It's a bit sad that there's no spec that actually matches the 3/3 shipping implementations, but oh well... Hopefully MDN documentation and the like will fill in that gap.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.
Reply all
Reply to author
Forward
0 new messages