Thanks for the reviews! I've updated webkit signals in ChromeStatus to "No signals" to better match the current state.
On Tuesday, September 1, 2026 at 11:28:24 AM UTC-7 Dan Clark wrote: > *> 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/a0e59a0b-dd57-4a04-94cc-6c384bef6951n%40chromium.org.
