W3C home > Mailing lists > Public > www-style@w3.org > May 2012

Re: [css3-text] feedback on 'word-break: keep-all;'

From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Date: Mon, 07 May 2012 18:27:10 +0800
Message-ID: <4FA7A37E.8030307@csail.mit.edu>
To: Koji Ishii <kojiishi@gluesoft.co.jp>
CC: Ambrose LI <ambrose.li@gmail.com>, fantasai <fantasai.lists@inkedblade.net>, WWW Style <www-style@w3.org>
(12/05/04 16:37), Koji Ishii wrote:
> I agree. Since CSS Text Level 3 doesn't define where line breaking opportunities occur, we should make this definition as diff, just like we do for the line-break property.
> UAX#14, 8.2 Examples of Customization, Example 3[1] states the behavior for Korean. The referenced material doesn't seem to be available online, unfortunately, but it states:
>> Only the intersections of ID/ID, AL/ID, and ID/AL are affected
> It looks to me that prohibiting break opportunities for these combination gives what we want here.

Yes, it is indeed closer to IE's implementation, if not the same,
although I haven't taken a serious check with each character :p Some
interesting consequences of this rule is:

1. It preserves breaking after hyphens.
2. It preserves breaking after fullwidth punctuation (and so it doesn't
just break after word separators).
3. It no longer breaks between an ideograph (including Korean
characters) and a latin character (AL/ID, ID/AL). This is somewhat
surprising to me, but IE9 already implements this. Perhaps it would be
worth checking with the Korean Interest Group again to see if that's

I have one remaining question which is also relevant to Ambrose's
question. If a browser is able to determine to some extent the word
boundaries of a run of Chinese or Japanese (it seems that WebKit
browsers can do this, with certain failures of course, for double click
word selection), can 'word-break: keep-all' make it break at these points?

I think this is probably too advanced and perhaps difficult to spec at
this level, although I am interested in what people think.

Received on Monday, 7 May 2012 10:27:45 UTC

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