Safari 18.4 shipped the text-autospace property, congraturations.

One thing we noticed is that its initial value is set to no-autospace (turn off the feature), while the spec defines it to be 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 from a few different 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 get the benefits from the text-autospace feature, they have to opt-in, either a) by removing the ASCII spaces, or b) by adding the replace keyword. This is different from the situation of the text-spacing-trim property where "on by default" can improve the typography of the most existing pages.

For other minor cases, authors 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 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.

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 where there is no benefits.

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