*> WebKit: Positive (https://github.com/WebKit/standards-positions/issues/714 <https://github.com/WebKit/standards-positions/issues/714>)* This looks like it's still "No signals".
Nevertheless, LGTM1 as this is catching up to Gecko on a nice quality-of-life feature with developer interest. On Thursday, August 27, 2026 at 11:54:23 AM UTC-7 Chromestatus wrote: > *Contact emails* > [email protected], [email protected] > > *Explainer* > https://developer.mozilla.org/docs/Web/CSS/symbols > > *Specification* > https://drafts.csswg.org/css-counter-styles-3/#symbols-function > > *Summary* > The CSS symbols() function lets authors define a counter style inline > instead of first declaring a named @counter-style at-rule. It builds an > anonymous counter style from a list of string symbols plus an optional > counting system (cyclic, numeric, alphabetic, symbolic, or fixed), and is > accepted as the counter style in list-style-type, the list-style shorthand, > and counter() / counters(). > > *Blink component* > Blink>CSS > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> > > *Web Feature ID* > https://github.com/web-platform-dx/web-features/issues/4203 > <https://webstatus.dev/features/https://github.com/web-platform-dx/web-features/issues/4203> > > > *Motivation* > Defining a custom list marker in CSS today requires authoring a named > @counter-style rule and referencing it by name, which is needlessly > verbose for one-off, anonymous markers. The symbols() function lets authors > define the same counter style inline, without inventing or managing a > global name. It works wherever a counter style is accepted, specifically in > list-style-type and the counter()/counters() functions. Gecko has supported > symbols() since 2015, but Blink and WebKit have not, so this addresses an > important interoperability gap. > > *Initial public proposal* > *No information provided* > > *TAG review* > Not needed. symbols() is already specified in CSS Counter Styles Level 3 > (Candidate Recommendation) and interoperably shipped in Firefox. This is a > catch-up implementation with no new API shape, so a TAG review is not > required. > > *TAG review status* > Not applicable > > *Goals for experimentation* > None > > *Risks* > > > *Interoperability and Compatibility* > Low. symbols() is standardized in CSS Counter Styles Level 3 (Candidate > Recommendation) and has shipped interoperably in Firefox since 2015. > Chromium currently treats symbols() as invalid and drops the declaration, > so implementing it is strictly additive and moves Chromium toward > interoperability rather than away from it. > > *Gecko*: Shipped/Shipping > > *WebKit*: Positive ( > https://github.com/WebKit/standards-positions/issues/714) > > *Web developers*: Positive We have a developer-filed bug asking for > symbols: Lack of support for CSS `symbols()` function ( > https://issues.chromium.org/issues/484510686), as well as a handful of > upvotes in the tracking bug Implement CSS counter styles level 3 > `symbols()` function (https://issues.chromium.org/issues/40747844). There > are also a few dev articles covering `symbols()` noting the lack of > cross-platform support ( > https://css-tricks.com/almanac/functions/s/symbols/ and > https://piccalil.li/blog/an-in-depth-guide-to-customising-lists-with-css/ > ). > > *Other signals*: > > *Ergonomics* > None. symbols() is a declarative CSS value parsed and rendered like > existing counter styles. It introduces no synchronous APIs, threading, or > timing constraints, and adds no performance concern beyond existing > @counter-style handling. > > *Activation* > None. The syntax is documented on MDN and interoperable with Firefox, so > developers can adopt it directly. @counter-style remains available as a > fallback in engines without support. > > *Security* > None. symbols() adds a CSS value syntax with no network, storage, or > script exposure. It introduces no new security-relevant surface beyond > existing counter-style parsing and rendering. > > *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. This is an additive CSS value; it does not deprecate or change the > behavior of any existing API, so it poses no WebView compatibility risk. > > > *Debuggability* > No new DevTools surface is required. symbols() values appear in the > Styles and Computed panes like other CSS values, and getComputedStyle() > round-trips the serialized value. > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > Yes > This is a platform-independent CSS parsing and layout feature with no > platform-specific dependencies, so it is supported on all six Blink > platforms. > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > Yes > Covered by upstream WPT at > css/css-counter-styles/counter-style-at-rule/symbols-function.html and > symbols-function-invalid.html , exercising all <symbols-type> values > (cyclic, numeric, alphabetic, symbolic, fixed) and use in > list-style-type , counter() , and counters() . Results: > https://wpt.fyi/results/css/css-counter-styles/counter-style-at-rule > > *Flag name on about://flags* > enable-experimental-web-platform-features > > *Finch feature name* > CSSSymbolsFunction > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/issues/40747844 > > *Measurement* > A UseCounter ( CSSSymbolsFunction ) was added to measure adoption of the > symbols() syntax > > *Non-OSS dependencies* > > Does the feature depend on any code or APIs outside the Chromium open > source repository and its open-source dependencies to function? > No. The feature is implemented entirely within Blink and has no > dependencies outside the Chromium open-source repository. > > *Estimated milestones* > Shipping on desktop 154 > Shipping on Android 154 > Shipping on WebView 154 > > *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. symbols() is stable in CSS Counter Styles Level 3 (CR) with no > open issues affecting its syntax or behavior. > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5146996093616128?gate=5558436461936640 > > *Links to previous Intent discussions* > Intent to Prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM4PR21MB4640B9E11FD5D8865D9B813F92CA2%40DM4PR21MB4640.namprd21.prod.outlook.com > > > This intent message was generated by Chrome Platform Status > <https://chromestatus.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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/77583bde-0b36-4734-933c-0978ec1e1083n%40chromium.org.
