- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Nov 2024 17:31:37 +0000
- To: public-css-archive@w3.org
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)` <details><summary>The full IRC log of that discussion</summary> <chrishtr> koji: this is about text autospace<br> <chrishtr> koji: there have been many discussions about this, now I'd like to bring it to the group<br> <chrishtr> koji: previous discussions led to complications<br> <chrishtr> koji: I and two other people made a proposal related to this to the Unicode working group, and it was accepted<br> <chrishtr> koji: it will be in public review soon as part of version 59<br> <chrishtr> koji: proposal is to switch the character categorization for autospace to align with version 59 of Unicode<br> <florian> q+<br> <chrishtr> rossen: and how long will version 59 take to publish?<br> <chrishtr> koji: not totally sure, maybe Jan or Feb?<br> <chrishtr> florian: as you said the set of issues were complicated<br> <Rossen1> ack florian<br> <chrishtr> florian: in principle, I think it's great that it's been taken up by Unicode and we should use it<br> <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?<br> <chrishtr> florian: there were also special cases about symbols, are those also handled?<br> <florian> s/some special cases/hangul and bopomofo<br> <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.<br> <chrishtr> koji: there are cases where people will want to override to adjust behavior, for things like printed typography<br> <chrishtr> koji: what we wanted to do in version 59 is to set a solid default value for code points<br> <koji> The current draft: https://www.unicode.org/L2/L2024/24259r-tr59-1-working-draft.html<br> <chrishtr> florian: the original thing had special cases around letters and numerals, but also possibly around symbols<br> <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.<br> <chrishtr> koji: I'm not sure if we want to split symbols and punctuation<br> <chrishtr> florian: I'm not sure we disagree, just noting that we had discussion<br> <fantasai> https://www.unicode.org/L2/L2024/24259r-tr59-1-working-draft.html#symbols-punctuation<br> <chrishtr> florian: I'm supportive of the intent of your proposal, just haven't had the time to read it<br> <chrishtr> rossen: does this mean you're ok accepting this as a forward-looking resolution?<br> <chrishtr> florian: depends on if others have reviewed, might suggest changes on review<br> <chrishtr> fantasai: suggest accepting this change since it's an improvement, and if we find adjustments we can modify the Unicode proposal<br> <chrishtr> koji: just wanted to note that the proposal in Unicode was reviewed and accepted already, as an indication of review<br> <chrishtr> jfkthame: noticed that it's proposed that the changes are disabled outside of CJK for now, is that right?<br> <chrishtr> koji: yes<br> <chrishtr> jfkthame: what about content that is Chinese but not marked as such (e.g. blog comments)<br> <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.<br> <chrishtr> koji: there's a chance that it would do the wrong thing on such documents<br> <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.<br> <chrishtr> jfkthame: reasonable answers, but not sure about the conclusion<br> <chrishtr> koji: I think this is in line with what we've done for other properties<br> <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.<br> <chrishtr> florian: things will improve less for Japanese and Korean than Chinese?<br> <chrishtr> koji: it wouldn't solve the performance issue to include non-explicit languages<br> <chrishtr> koji: sub-optimal rendering would also result<br> <Rossen1> ack fantasai<br> <chrishtr> fantasai: wanted to express the same thing as Jonathan Kew<br> <chrishtr> fantasai: propose to accept UTR 59 but leave the question of in what situations to apply the behavior open<br> <chrishtr> fantasai: I lean towards what Jonathan and Florian are saying and trying to make it work when we can<br> <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?<br> <chrishtr> fantasai: I think that's open. We should ideally try to make it work in all documents if we can find a way.<br> <chrishtr> florian: agree with the proposed resolution<br> <fantasai> PROPOSED: Adopt forthcoming UTR#59 as basis for text-autospace character classifications (deferring question of default behavior to a new issue)<br> <florian> s/the proposed resolution/the proposed two-part resolution<br> <chrishtr> RESOLVED: Adopt forthcoming UTR#59 as basis for text-autospace character classifications (deferring question of default behavior to a new issue)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11013#issuecomment-2504430075 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 November 2024 17:31:38 UTC