W3C home > Mailing lists > Public > public-i18n-cjk@w3.org > July to September 2016

Re: [css-text][css-writing-modes] Line breaking around Emoji, Gaiji, U+FFFC, and text-combine-horizontal

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sat, 24 Sep 2016 18:00:32 +0100
To: public-i18n-cjk@w3.org
Message-ID: <87e9fa50-62c9-9cd8-2e94-ace28ff5bf71@inkedblade.net>
On 01/14/2015 01:01 PM, Koji Ishii wrote:
> A rather recent fix for CSS Text introduced a new line breaking
> behavior in 5.1 Line Breaking Details[1], as quoted here:
>> The line breaking behavior of a replaced element or other atomic inline
>> is equivalent to that of the Object Replacement Character (U+FFFC) and
>> introduces a soft wrap opportunityboth before and after itself. For
>> Web-compatibility, this rule take precedence over WJ and GL handling;
>> in terms of [UAX14], this shifts the CB rule (LB20) immediately above
>> the WJ and GLrules (LB11/LB12).
> Although this was done for web-compat, I found it has two unfortunate
> side-effects:
> 1. Can break between image-based characters and, say, period or
> closing parenthesis. Emoji is emerging as I understand. East Asian
> Gaiji usage may decrease its use, but it'll still take a while.
> 2. text-combine-horizontal defines it to be U+FFFC for line breaking
> purposes[2], and this change in CSS Text broke its assumptions to work
> properly.
> Fixing #2 is easy, we can change CSS Writing Modes to use one of
> ideographic characters. Ruby has the same issue, I just replied to
> that[3], but this can also be handled in ruby spec. Any ideographic
> characters are fine with me, if I were to choose, let's say U+4E00,
> the first ideographic character in the Unicode order.

Just to follow up on this, the CSSWG resolved to use the ID line-breaking
class for atomic inlines (such as images). The one weird bit was that,
for Web-compatibility reasons, we had to define this line-breaking
opportunity to take precedence over &nbsp;. :(

Many thanks to Opera's Presto engine for making this improvement possible.

Received on Saturday, 24 September 2016 22:30:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 26 October 2016 23:39:18 UTC