[csswg-drafts] [css-text] Reconsider the initial value of the `text-autospace` property (#12386)

kojiishi has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-text] Reconsider the initial value of the `text-autospace` property ==
[Safari 18.4 shipped](https://developer.apple.com/documentation/safari-release-notes/safari-18_4-release-notes#:~:text=Added%20support%20for%20text%2Dautospace.%20(140008990)) the `text-autospace` property, congraturations.

One thing we noticed is that its initial value is set to [`no-autospace`](https://drafts.csswg.org/css-text-4/#valdef-text-autospace-no-autospace) (turn off the feature), while [the spec](https://drafts.csswg.org/css-text-4/#text-autospace-property) defines it to be [`normal`](https://drafts.csswg.org/css-text-4/#valdef-text-autospace-normal) (turn on the feature). With this opportunity, I'd like us to discuss which is the better initial value for the `text-autospace`.

Here's my investigations on perspectives.

### For East Asian Authors and Users

Whether "on by default" or "off by default" doesn't make any differences in the majority of cases, because most existing pages have an ASCII space to where the `text-autospace` would insert the space, part because it's the tradition since 1980, part because the majority of style guides require to do so.

For these majority to take benefits from the `text-autospace`, they have to opt-in to get the benefits from this feature, either a) by removing the ASCII spaces, or b) by adding the [`replace`](https://drafts.csswg.org/css-text-4/#valdef-text-autospace-replace) keyword. This is different from the situation of the [`text-spacing-trim`](https://drafts.csswg.org/css-text-4/#propdef-text-spacing-trim) property where "on by default" can improve the typography of the most existing pages.

For other minor cases, authors are either a) don't care, or b) explicitly preferred tighter spacing. In the former case, either initial value works fine. The latter case would prefer "off by default".

### For Non-East Asian Scripts

For non-East Asian scripts, turning this feature on has no impacts, or sometimes negative. Most these scripts use space to delimit words, so East Asian characters appearing as a word has no differences by this feature. In rare cases, a word may consist of East Asian characters and non-East Asian letters, such as proper nouns. In such cases, the spacing is either a) not noticed, or b) it could confuse as if there's an actual space.

### Performance

This feature hits the performance in a lot higher degree than other similar features such as the [`text-spacing-trim`](https://drafts.csswg.org/css-text-4/#propdef-text-spacing-trim) property because it has a lot more candidate characters, spread across Unicode blocks. Implementing an optimization to skip most of the computation when not applicable succeeds less. The current Blink implementation can avoid most of the performance hits for Latin scripts, but all other scripts are impacted by 1-5% of the layout time.

In addition to the WebKit shipping "off by default", @masayuki-nakano, a Japanese Gecko engineer, also [expressed a concern about the performance hit](https://github.com/mozilla/standards-positions/issues/903#issuecomment-1928880823).

### Options

We have options to:
1. Make `normal` (turn on) as the initial value (the current spec).
2. Make `no-autospace` (turn off) as the initial value (what WebKit shipped).
3. Make the `replace` as the initial value.

While the option 3 `replace` can improve the majority of existing pages without requiring authors to opt-in, it could be too aggressive, may alter the semantics in the way authors don't expect. I'm hesitant to make it the default behavior.

I'm fine with 1 or 2, because either option doesn't make any differences in the majority cases of East Asian authors and users as stated above, but mildly prefer 2 given the performance hits, especially to non-CJK, non-Latin scripts.

/cc @fantasai @frivoal @nt1m @vitorroriz @masayuki-nakano @jfkthame @bfgeek @chrishtr @clqsin45

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12386 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 23 June 2025 10:40:01 UTC