W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2020

Re: [csswg-drafts] [css-text-3] Segment Break Transformation Rules around CJK Punctuation (#5086)

From: Shinyu Murakami via GitHub <sysbot+gh@w3.org>
Date: Sun, 24 May 2020 18:35:35 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-633273996-1590345334-sysbot+gh@w3.org>
> The semantic line feed is great if we can get perfect on that.

Yes, we can get perfect on that because my proposal is for enabling semantic linefeeds at CJK punctuation such as [。、.,] without causing extra space. Authors will not need to know any rules but can put linefeeds at end of sentence (full stop) and at (fullwidth/ideographic) comma and other punctuations.

You may argue that it's not perfect because putting linefeeds around quotation marks [‘’“”] (not belong to the space-discarding character set) may cause unexpected space (as discussed in #5017 ). But we can say "don't break at ambiguous punctuations if you don't want extra space."

> In that circumstance, I think easy-to-predict is more important than making it a little smarter.

Your "easy-to-predict" will not be easy to predict for many users. I repeat: it will be hard to predict that a linefeed after a CJK punctuation will cause extra space depending on the following character.

Adding the rule around CJK punctuation is not just "making a little smarter". Without this rule, semantic linefeeds are not possible for Japanese and Chinese.

>  Just to be clear, my position stays; i.e., if Unicode adds a property for this purpose, CSS can use it. If you want to put more rules to make it smarter, I recommend to discuss at Unicode.

The rule I proposed uses only existing Unicode properties and the [space-discarding character set](https://drafts.csswg.org/css-text-3/#space-discard-set). So I don't understand why new Unicode property is necessary.


-- 
GitHub Notification of comment by MurakamiShinyu
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5086#issuecomment-633273996 using your GitHub account
Received on Sunday, 24 May 2020 18:35:38 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:07 UTC