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

[css3-text] require UAX#14 for line breaks in CSS? (was line-break questions/comments

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Mon, 27 Aug 2012 05:23:18 -0400
To: Glenn Adams <glenn@skynav.com>
CC: W3C Style <www-style@w3.org>, "public-i18n-cjk@w3.org" <public-i18n-cjk@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0D5E63C253@MAILR001.mail.lan>
I split line breaking and UAX#14 issue into this separate thread.

>> IE, for instance, uses 'normal' as 'auto', and doesn't use ICU. It's mostly
>> the same as the normal ja settings of ICU50, but not exactly the same.
>> I don't see much user value for IE to implement exactly the same line
>> breaking as UAX#14 and changing 'auto' to it.
> I doubt it. That is, I doubt that IE uses *only* the rules defined by 'normal'
> if set to 'auto'. At present, auto (and the other values are pretty much
> *completely* non-interoperable or even testable except for the extremely
> small number of rules explicitly defined. I very much doubt that users
> would be satisfied if *only* the rules specified under the definition of this
> property were applied to text of any language, including CJK.

I guess you're mixing two things here; the default line breaking rule is defined in section 5.1. The line-break property gives an additional control to authors over what were defined in section 5.1, and therefore it is optional if a UA has no interests in Japanese market. That is why the property is defined as differences rather than sets.

So, what you're asking is to change section 5.1 Line Breaking Details to require UAX#14. I do not see any user/author values doing this; hyphenation is UA dependent, fonts vary, just requiring UAX#14 doesn't improve anything in real world. If you have a good reason to do this, we can discuss, but I think it's so big change from CSS2 that I'd probably ask WG resolution for this change.

>> UAX#14 has several character classes that change their behavior by
>> application's input. AI or CJ classes for example, so there's no single
>> UAX#14 line breaking. Also UAX#14 changes over time, ICU changes
>> how to interpret classes like AI or CJ by versions, and UAs take different
>> versions of ICU, so just adding 'uax14' doesn't help much.
> I disagree. It provides a concrete point of departure when what is currently
> specified is "whatever you want". The issue of versioning and AI/CJ are not
> sufficient reason to not reference or define a uax14 keyword.

There's no author's need to add the value. As far as I understand, we don't want to add a value for testing purpose into CSS.

> At minimum, we should define a "uax14" keyword, intentionally leaving
> version and AI/CJ UA dependent (which could be resolved or parameterized
> in the future).

What values does it gives to authors/users?

>> Because we don't define the baseline, we can't say this. The baseline is
>> UA dependent, and we define the minimum differences between values.
> We define baselines (i.e., default behavior) in many other cases. We should
> do so here as well. Failing to do so just produces non-interoperability. What
> is the point of defining line-break if 90% of the behavior is unspecified?
> That seems to be a poor design principle: i.e., throw out some tokens
> (loose, strict), and let UAs do whatever they want. We can do better and should.

We didn't define in CSS2, and no complaints heard so far from authors and users. Good for testing doesn't sound like a good reason to add a value to me.

Line break has not been and will not be interoperable in a re-flowable format such as HTML. We cannot standardize fonts widths or hyphenation dictionary. And as said above, since UAX#14 keeps changing, requiring UAX#14 doesn't solve interoperability issue at all.


Received on Monday, 27 August 2012 09:25:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:10:23 UTC