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

@kojiishi 

What decisions do you want to make by when in this issue?

I can see two possibilities.

- (P1) What should be the initial value of `text-autospace` in the CSS specification?
- (P2) What should be the initial value in the implementation of the browser to be released soon?

> I'd like to clarify that this is a discussion of what the "good" rendering is. Performance and web-compat were the original reasons to start this discussion, and they're still part of the reasons,

The point of this discussion is the review items for browser implementation in (P2), not the review items for the CSS specification in (P1), right?

> There were more cases where the autospace hindered the readability, while dogfooding default-on. Not too many though, like once a week or two, except dates where I always prefer no-autospace.

The following Japanese sentences are examples.

- (A) No space
    - 私は2000年頃からHTMLを研究していて、HTML仕様やWebページ、HTMLリソースの在り方について考察しています。MDNやAstroの日本語翻訳コントリビューターもしています。
- (B) Space available (not ASCII space, but space added by `text-autospace`)
    - 私は 2000 年頃から HTML を研究していて、HTML 仕様や Web ページ、HTML リソースの在り方について考察しています。MDN や Astro の日本語翻訳コントリビューターもしています。

For example, are the reasons for "There were more cases where the autospace hindered the readability" as follows?

- (R1) The text becomes difficult to read because the character spacing is increased by 1/8 of the ideographic advance (0.125ic) before and after alphanumeric characters.
- (R2) The problem is not so much that spaces are added before and after alphanumeric characters, but rather that this results in an increase in the number of lines in a paragraph, which in turn increases the vertical space required.
- (R3) Or it is for performance reasons.

It is understandable to be concerned that, in some cases, the problem described in (R2) may arise due to an increase in the number of lines in a paragraph caused by the spacing that is increased by 1/8 of the ideographic advance (0.125ic) resulting from `text-autospace: normal` being applied to mixed Japanese and Western text that was originally written without ASCII spaces.

However, I think it is wrong to conclude that the initial value of the `text-autospace` property should not be set to `normal`, regardless of whether the purpose is (P1) or (P2).

This is because, since `text-autospace: normal` was not previously enabled, ASCII spaces were inserted before and after alphanumeric characters. With `text-autospace: normal` enabled, the width of such documents will become shorter (as ASCII spaces can now be removed).

> but it is now clear that a good number of authors prefer no-autospace 
because it is "good" rendering.
>
>  In my personal opinion, I'd turn it on when the content has taller line-height (1.8 or more, common Japanese printing setting), and uses Latin fonts for Latin letters/digits. In other cases, no-autospace looks better rendering to me.

I cannot understand the reasoning behind the conclusion that no auto space is "good" rendering. I cannot agree because I do not understand the reasoning behind the "conditions that should be enforced" that you have indicated.

I would like to confirm something with you.

- (Q1) Which of (P1) or (P2) would you like to discuss?
- (Q2) Which of (R1), (R2), or (R3) are the negative effects of auto-spacing?
- (Q3) Do you think that text in which there is a 1/2 width space between alphanumeric characters due to the presence of ASCII spaces is “bad”?
- (Q4) Do you think it is a negative effect (from a web-compatibility perspective) when text that was previously 0 width space becomes 1/8 width space due to auto-spacing?
- (Q5) Do you think there is a problem with the readability of text that is 0 width space between alphanumeric characters?

You don't have to answer all the questions, but please clarify your views.

-- 
GitHub Notification of comment by debiru
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12386#issuecomment-3171987790 using your GitHub account


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

Received on Saturday, 9 August 2025 18:02:32 UTC