Intent to Ship: CSS counter() and counters() in alt text of 'content' property

[Daniil Sakhapov]

Contact emails

sakh...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/css-content/#content-property

Summary

counter() and counters() in alt text of 'content' property is useful to provide more meaningful information to e.g. pseudo elements to improve their accessibility.

Blink component

Blink>CSS

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

It's currently "At risk" https://github.com/w3c/csswg-drafts/issues/10387

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1253)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/515)

Web developers: No signals

Other signals:

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

None

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?

Yes

http://wpt.fyi/css/css-content/parsing/content-counter-valid.html http://wpt.fyi/accname/name/comp_name_from_content.html http://wpt.fyi/accname/name/comp_name_from_content_alt_counter_invalidation.html

Flag name on about://flags

CSSAltCounter

Finch feature name

None

Non-finch justification

None

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/417488055

Estimated milestones

DevTrial on desktop	138
DevTrial on Android	138

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/5185442420621312?gate=5133455599599616

This intent message was generated by Chrome Platform Status.

[Vladimir Levin]

This feature seems to be marked at-risk due to implementation complexity. It isn't clear whether this would mean that to implement this, some features have to be less performant. Do you expect that this feature adds any performance problems?

I also had a question about the lack of Web Developer signals: are there any that you know of?

Thanks!

Vlad

[Daniil Sakhapov]

For Blink there are no performance issues as counter value calculation is performed at the same time as for other counters, so it's not really any different from just using counter().

As the real use case for this feature appeared only with Carousel primitives introduction, I don't know of any signals from web devs, but a11y people support it and it's per OpenUI recommendations for Carousels.

ср, 25 июн. 2025 г. в 04:11, Vladimir Levin <vmp...@chromium.org>:

[Chris Harrelson]

LGTM1

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH3Z928W%3D%2BbSPB2nr81kOi%3D24UN2-JxEn6Yt8j5Pqggef18H-w%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

LGTM2 conditional on two things:
1) Removing the "at risk" label from the spec

2) Including an example in the spec and relevant documentation about *how* developers are supposed to use this.

Specifically for (2), since the presence of `counter()` breaks the "content:" property (as it's invalid syntax in non-supporting browsers), we want developers that are using this to also provide a `content:` property that doesn't include a `counter()` and precedes the one that does.

This needs to be *very* clear to developers that are reaching out for this tool. 

(and right now it isn't. Jeffrey Yasskin on the API owners call mentioned this is a correct fallback for developers to use)

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

[Daniel Bratell]

LGTM3 (per Yoav's description)

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01c59ac6-5629-4817-ada9-6bc1fd979f4dn%40chromium.org.

[Tab Atkins Jr.]

On Wed, Jul 2, 2025 at 8:40 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

LGTM2 conditional on two things:
1) Removing the "at risk" label from the spec

"At Risk" is a W3C term of art that simply indicates, for legal purposes, that the WG is allowed to remove that feature from a CR spec without having to return to WD; the post-removal spec can just be republished as a CR immediately. It is solely a tool for reducing bureaucracy a little bit. It does not actually indicate that a feature is risky in any way, or *likely* to be removed, or have any other legal implications. (Yes, this has been a persistent source of confusion for decades, but it's never been important enough for anyone to make an effort to change it.)

Since the spec isn't even *in* CR yet, it doesn't even give us that benefit, fwiw. But neither does it hurt us in any way. It's completely reasonable to have a feature that is currently single-implementation marked as At Risk, just in case. I don't think there's any chance of it being removed, but you never know.

We should not be gating shipping approval on this.

~TJ