Description
The current CSS Counter Styles Level 3 specification intentionally limits all CJK longhand counter styles to a range of -9999 to 9999. While CJK style range extensions are “allowed", there is no clear specification.
The current WPT expects these styles to work with much larger values (up to 1,000,000,000 in the current test case), and there is a fundamental mismatch between the spec's limitation and WPT expectations or real-world requirements for CJK number representation. Moreover, Firefox already has an extension implementation, so a cross-browser incompatibility exists as well.
e.g, japanese-informal) https://wpt.fyi/results/css/css-counter-styles/japanese-informal/counter-japanese-informal.html
Current Spec Issues
-
Intentional Range Limitation: The spec defines
range: -9999 9999;for all CJK longhand styles with a note that "opinions differ on how best to represent numbers 10k or greater." This limitation is problematic because:- Unlike the Western system of 1,000 units, East Asian languages use myriad-based systems with natural breakpoints at 10,000 (万/萬/만), 100,000,000 (億/억), etc.
- more details can be found here: Japanese numerals
- This structural difference makes implementation using the current additive system difficult
- The limitation prevents proper representation of common large numbers in CJK languages
- All affected counter styles share similar structural patterns for large numbers
- Unlike the Western system of 1,000 units, East Asian languages use myriad-based systems with natural breakpoints at 10,000 (万/萬/만), 100,000,000 (億/억), etc.
-
Incomplete additive-symbols: The current definition only goes up to 9000 on purpose:
additive-symbols: 9000 \4E5D\9621, 8000 \516B\9621, ... /* stops at thousands */
-
Test-Spec Mismatch:
| number | Actual(Spec) | Expected(WPT) |
|---|---|---|
| 10,000 | 10000 | 壱萬 |
| 100,000 | 100000 | 壱拾萬 |
| 1,000,000 | 1000000 | 壱百萬 |
| 100,000,000 | 100000000 | 壱億 |
| 1,000,000,000 | 1000000000 | 壱拾億 |
Browser Implementation Status
- ✅ Gecko: Supports extended ranges beyond the spec
- ❌ WebKit: Follows spec limitation and fails WPT tests for values > 9999
- CJK counterstyle support was added in 2021. It uses the
toPredefinedAdditiveSystem()to implement the additive system algorithm. (see [Bug 227206](https://bugs.webkit.org/show_bug.cgi?id=227206)).
- CJK counterstyle support was added in 2021. It uses the
- ❌ Chromium: Follows spec limitation and fails WPT tests for values > 9999
This creates inconsistent cross-browser behaviour, and specs side should better to be fixed because WPT expectations are natural (, moreover, current outputs are quite not true) in the real world.
Proposed Solutions
-
The range restriction relaxation
range: auto; /* or -999999999 999999999 to pass the current testcases at least*/
Allow implementations to extend support.
-
Extend additive-symbols
7970
Add symbols for myriad units (万/萬/만) and higher denominations to properly support CJK numbering systems. Example for Japanese:additive-symbols: 100000000 \58F1\5104, /* 壱億 */ 10000000 \58F1\9621\4E07, /* 壱阡萬 */ 1000000 \58F1\767E\4E07, /* 壱百萬 */ 100000 \58F1\62FE\4E07, /* 壱拾萬 */ 10000 \58F1\4E07, /* 壱萬 */ /* ... existing symbols ... */
Similar extensions would be needed for Korean and Chinese variants.
Then, fallback to extended CJK style instead ofcjk-decimal. -
Long-term: Consider a new algorithmic approach for CJK
For CJK counter styles that follow predictable patterns, a CJK-specific algorithmic system might be more appropriate than additive for very large numbers. e.g,system: cjk-algorithmic;?
References
- Current spec: https://drafts.csswg.org/css-counter-styles/#complex-predefined-counters
- WPT test expecting large values: [counter-japanese-formal.html](https://github.com/web-platform-tests/wpt/blob/master/css/css-counter-styles/counter-japanese-formal.html)
- Related discussion on range limitations: [css-counter-styles] range fallback is neither widely implemented nor sensible as specified #2479
Impact
This change would:
- Align the specification with actual test expectations
- Enable proper CJK number formatting for common use cases across East Asian languages
- Improve cross-browser compatibility
- (Better support internationalization requirements for a significant portion of the world's population)
Note: While this issue uses Japanese examples, the same structural issues and solutions would apply to all CJK longhand counter styles defined in the specification.
I would like to see everyone implement the same range for CJK in the right way and have it specified in the specification.
cc: @nt1m