W3C home > Mailing lists > Public > www-style@w3.org > January 2015

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

From: Koji Ishii <kojiishi@gmail.com>
Date: Tue, 27 Jan 2015 22:41:27 +0900
Message-ID: <CAN9ydbWfS2X-tW=r3tFAGe-tCpssHqd7HJityEHoPoLSqvxK8Q@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "www-style@w3.org" <www-style@w3.org>
On Tue, Jan 27, 2015 at 5:00 AM, fantasai <fantasai.lists@inkedblade.net>
wrote:

>
>  This property is to opt-out the fix and bring back the behavior
>> we defined in the LC, so I think we need this in the Level 3.
>>
>
> The ideal behavior is, I think, to treat as ID. I can't imagine
> anyone intentionally *wanting* the current behavior (ignoring
> nbsp etc.)
>
>
> FWIW, just checked Presto with some of your test cases (using
> comma, period, brackets, etc.), and it seems to treat images
> as ideographic. E.g. it keeps an image together with an
> immediately following close-bracket, comma, or period. This
> means it was Web-compatible enough for Presto, so maybe it's
> Web-compatible enough for everyone.
>
> I propose we treat TCY, U+FFFC, and images all as ID by default.
> What do you think?


It's great if we can make that. UAX#14 LB1 says "resolve CB... to other
classes" so I guess it's good from that perspective too IIUC.

The only concern is web-compat. We knew Presto doing as defined in LC,
Kenny pointed out in his original mail, but we were too scared to change
all other browsers and that's why we fixed the way it is in the spec today.
Practically speaking, if impls don't see enough values to break existing
sites and don't follow the spec, we can't solve the problem. From that
perspective, I have mild preference to keep the legacy but allow authors to
opt-in to the ideal behavior for emoji.

But I also feel that it's not a proper approach for the web to evolve. I'd
like to know what others would say on this balance.

/koji
Received on Tuesday, 27 January 2015 13:41:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:50 UTC