[css-text] Use the Unicode East Asian Auto Spacing for `text-autospace`

[kojiishi]

Currently, the text-autospace property defines its own character classes for the East Asian inter-script spacing. Then discussions started on multiple code points (#9471, #9479, #9501, #9503, #9979, #9980), and even more at the Unicode.

The Unicode Technical Comittee accepted L2/24-057R East Asian Auto Spacing (Proposal) and are preparing a working draft UTR as in the minutes [180-A82].

Can the CSS spec refer to the UTR?

@fantasai @frivoal @xfq @kidayasuo @MurakamiShinyu @nt1m @vitorroriz @Clqsin45 @bfgeek @chrishtr

[kojiishi]

To be more precise, the proposal is to change the "8.5.2. Text Spacing Character Classes" to:

ideogrpahs:

• All characters where the Unicode East Asian Auto Spacing property [UTR#number-TBD, L2-24-057R]] is W.

non-ideographic letters or numerals

• If the content language is Chinese or its macrolanguages, all characters where the Unicode East Asian Auto Spacing property is N or C.
• Otherwise, if the content language is Japanese or Korean, all characters where the Unicode East Asian Auto Spacing property is N.
• Otherwise no characters in this class (please see notes below).

non-ideographic letters

• All non-ideographic letters or numerals characters that don't belong to the Unicode Decimal Digit Number [Nd] general category.

non-ideographic numerals

• All non-ideographic letters or numerals characters that belong to the Unicode Decimal Digit Number [Nd] general category.

Notes on the content language:

• We may need to define "Chinese or its macrolanguages" more clearly.
• The last "otherwise" is for the performance reasons. The current definitions allows implementers to optimize the performance by using script boundaries, but using the Unicode property will make it more difficult. From our prototype, this feature will impact the line breaking performance by a few percent if without the script boundary optimization. The last "otherwise" helps not applying the algorithm for non-CJK content.

[css-meeting-bot]

The CSS Working Group just discussed [css-text] Use the Unicode East Asian Auto Spacing for `text-autospace` , and agreed to the following:

• RESOLVED: Adopt forthcoming UTR#59 as basis for text-autospace character classifications (deferring question of default behavior to a new issue)

The full IRC log of that discussion

<chrishtr> koji: this is about text autospace
<chrishtr> koji: there have been many discussions about this, now I'd like to bring it to the group
<chrishtr> koji: previous discussions led to complications
<chrishtr> koji: I and two other people made a proposal related to this to the Unicode working group, and it was accepted
<chrishtr> koji: it will be in public review soon as part of version 59
<chrishtr> koji: proposal is to switch the character categorization for autospace to align with version 59 of Unicode
<florian> q+
<chrishtr> rossen: and how long will version 59 take to publish?
<chrishtr> koji: not totally sure, maybe Jan or Feb?
<chrishtr> florian: as you said the set of issues were complicated
<Rossen1> ack florian
<chrishtr> florian: in principle, I think it's great that it's been taken up by Unicode and we should use it
<chrishtr> florian: follow-up questions. Some of the things we discussed previously were not regular full-width characters but some special cases, and how to deal with those. Am I right that this Unicode proposal deals with all those special cases in CJK?
<chrishtr> florian: there were also special cases about symbols, are those also handled?
<florian> s/some special cases/hangul and bopomofo
<chrishtr> koji: similar to utr 50, this doesn't do exactly the same thing as e.g. MS Word as it relates to these half-width or ambiguous characters, but it is close.
<chrishtr> koji: there are cases where people will want to override to adjust behavior, for things like printed typography
<chrishtr> koji: what we wanted to do in version 59 is to set a solid default value for code points
<koji> The current draft: https://www.unicode.org/L2/L2024/24259r-tr59-1-working-draft.html
<chrishtr> florian: the original thing had special cases around letters and numerals, but also possibly around symbols
<chrishtr> koji: the current draft of the Unicode proposal (posted in chat) classifies values to W and N and if CSS wants more control we will need to use general categories to split W into multiple pieces.
<chrishtr> koji: I'm not sure if we want to split symbols and punctuation
<chrishtr> florian: I'm not sure we disagree, just noting that we had discussion
<fantasai> https://www.unicode.org/L2/L2024/24259r-tr59-1-working-draft.html#symbols-punctuation
<chrishtr> florian: I'm supportive of the intent of your proposal, just haven't had the time to read it
<chrishtr> rossen: does this mean you're ok accepting this as a forward-looking resolution?
<chrishtr> florian: depends on if others have reviewed, might suggest changes on review
<chrishtr> fantasai: suggest accepting this change since it's an improvement, and if we find adjustments we can modify the Unicode proposal
<chrishtr> koji: just wanted to note that the proposal in Unicode was reviewed and accepted already, as an indication of review
<chrishtr> jfkthame: noticed that it's proposed that the changes are disabled outside of CJK for now, is that right?
<chrishtr> koji: yes
<chrishtr> jfkthame: what about content that is Chinese but not marked as such (e.g. blog comments)
<chrishtr> koji: this is a good point. the reasons I proposed it that way is that the property value is different between Chines and non-Chinese. If we applied to a document that is not Chinese we need a default for that document.
<chrishtr> koji: there's a chance that it would do the wrong thing on such documents
<chrishtr> koji: another reason is performance. This will slow down layout 1-3% due to additional complexity, and so limit it to the languages where it has clear user benefit.
<chrishtr> jfkthame: reasonable answers, but not sure about the conclusion
<chrishtr> koji: I think this is in line with what we've done for other properties
<chrishtr> jfkthame: agree that it's aligned with things like hyphenation. But in the case of hyphenation it could be wrong, whereas here it wouldn't be wrong but it would be a bit less good than it might be.
<chrishtr> florian: things will improve less for Japanese and Korean than Chinese?
<chrishtr> koji: it wouldn't solve the performance issue to include non-explicit languages
<chrishtr> koji: sub-optimal rendering would also result
<Rossen1> ack fantasai
<chrishtr> fantasai: wanted to express the same thing as Jonathan Kew
<chrishtr> fantasai: propose to accept UTR 59 but leave the question of in what situations to apply the behavior open
<chrishtr> fantasai: I lean towards what Jonathan and Florian are saying and trying to make it work when we can
<chrishtr> koji: I can file a new issue. To clarify, we're leaving undefined if the language is not specified, but not do it in English document?
<chrishtr> fantasai: I think that's open. We should ideally try to make it work in all documents if we can find a way.
<chrishtr> florian: agree with the proposed resolution
<fantasai> PROPOSED: Adopt forthcoming UTR#59 as basis for text-autospace character classifications (deferring question of default behavior to a new issue)
<florian> s/the proposed resolution/the proposed two-part resolution
<chrishtr> RESOLVED: Adopt forthcoming UTR#59 as basis for text-autospace character classifications (deferring question of default behavior to a new issue)