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: Fri, 22 May 2020 03:10:30 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-632453995-1590117029-sysbot+gh@w3.org>
> > * Otherwise, if either the character before or after the segment break belongs to the space-discarding character set and is a Unicode Punctuation (P*) or Space Separator (Zs), then the segment break is removed.
> 
> Are you sure you want to remove the segment break for:
> 
> > First sentence.
> > Second sentence.
> 
> to produce:
> 
> > First sentence.Second sentence.

No.
The rule I wrote is "… belongs to the space-discarding character set and is a Unicode Punctuation (P*)…."
The (non fullwidth) full stop U+002E (.) does not belong to the [space-discarding character set](https://drafts.csswg.org/css-text-3/#space-discard-set), so this rule is not applied in this case.

> We discussed this in JLTF ML but I'm not positive. This allows line breaking after punctuation and that is nice, but when authors need to make adjustments anyway as @r12a pointed out in some other issue, adding this rule makes authors hard to predict whether a space will be inserted or not. I think easier to predict is more important than the cases it helps.

I think it will be hard to predict that a linefeed after a CJK punctuation will cause extra space depending on the following character.
And that makes [semantic linefeeds](https://rhodesmill.org/brandon/2012/one-sentence-per-line/) (mentioned by @xfq) impossible. Why can you ignore this requirement?

-- 
GitHub Notification of comment by MurakamiShinyu
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5086#issuecomment-632453995 using your GitHub account
Received on Friday, 22 May 2020 03:10:31 UTC

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