RE: [css3-text] scoping line break controls, characters that disappear at the end of lines

After looking into this issue further and by re-reading UAX#14, let me try to re-summarize this issue.

By comparing IE's behavior and "The White Space Processing Rules" in CSS Text Level 3[1], IE's default behavior can be explained as handling ideographic spaces as no-break-before, non-collapsible spaces regardless of text-space-collapse. This behavior is similar to MS Word, and JLTF thinks this behavior is acceptable, though not ideal.

Firefox. I failed to figure out its behavior last time but I think I got it; it probably handles ideographic spaces as no-break-before non-collapsible spaces. JLTF thinks this behavior is also acceptable, or sometimes even better than IE's behavior (it depends on what to put priority on; less expansion v.s. leaving spaces at line end.)

Safari/Chrome/Opera are consistent here and they all handle ideographic spaces as regular ideographic characters. This behavior actually aligns to what CSS Text Level 3 says today, and to UAX#14[2] which defines U+3000 as ID (ideograhic.) This behavior is also similar to InDesign, but JLTF thinks this is not acceptable for the Web, and I agree with it. Ok for print because authors can manually edit, and actually if you think about editing, this method has advantages than other methods, but it doesn't fit well for re-flowable contents like HTML.

Honorific spaces in traditional Chinese and some other use cases of ideographic spaces in Japan require ideographic spaces as regular ideographic characters, but do not want it to appear after wrap. In this regard, Firefox works the best here, and IE can work around by using text-wrap:nowrap to avoid collapsing by the rule 4 of "after lines are laid out" in "The White Space Processing Rules."

So my recommendation is to use IE or Firefox behavior as above for ideographic spaces. If the WG wants to leave this as UA dependent as Kenny said, I can live with it, but as a Japanese user, I wish Safari/Chrome/Opera to follow either IE or Firefox behavior.

For other fixed spaces, I don't have strong opinions, nor anyone I asked around. IE/Safari/Chrome/Opera handles it as non-spaces (although break opportunities are different between IE and Safari/Chrome/Opera,) and Firefox handles it as no-break-before non-collapsible spaces, just like it handles ideographic spaces.

If UA follows UAX#14, they are either GL (no-break-before-and-after) or BA (no-break-before,) neither of which can appear after wrap, so Firefox behavior makes the most sense to me.

For use cases like space for French guillements[3] or similar spaces in Japanese, I want them to disappear if line wraps there, but I don't know other uses cases much, nor if the WG has a motivation to standardize it, also as Kenny pointed out.

[1] http://dev.w3.org/csswg/css3-text/#white-space-rules

[2] http://unicode.org/reports/tr14/

[3] http://lists.w3.org/Archives/Public/www-style/2004Aug/0070.html


Regards,
Koji

Received on Sunday, 6 May 2012 13:08:04 UTC