RE: [css3-text] Splitting CSS Text into Level 3 and Level 4

Thanks for the reply, John, and sorry that I didn't do good job clarifying what I wanted to say. I wanted to say that, I agree with you on "looking for more flexible approaches" is good, but we think differently on which approach is more flexible.

> Basing solutions on actual usage allows us to avoid defining features
> that are never widely used in practice but widely implemented simply
> to satisfy the requirements of a given spec.

Again, I agree on this general idea, but we think differently how to do it. By defining "a very simple version" at this point, I think we take a risk to define too much to support "full-size-kana".

"full-size-kana" only requires one-to-one code point transformation. But Florian's Wiki[1] and ideas at ML require a lot more. Most of them require inheritance, grapheme clusters, word boundaries, and Unicode normalizations. How much of them do you intend to put in Level 3?

With so many wishes and scenarios, I think not to define @text-transform in level 3 gives more flexibility to us. If we define something, we may be in trouble to extend it in Level 4 to keep backward compatibility.

So what I'm saying is, to achieve the goal you're saying, I think not defining a very simple version in Level 3 is better. Did I make myself clear?

[1] http://wiki.csswg.org/ideas:at-text-transform


Regards,
Koji

-----Original Message-----
From: John Daggett [mailto:jdaggett@mozilla.com] 
Sent: Monday, December 12, 2011 9:31 AM
To: Koji Ishii
Cc: www-style@w3.org
Subject: Re: [css3-text] Splitting CSS Text into Level 3 and Level 4

Koji Ishii wrote:

> I agree with fantasai. Floarian's proposal and following discussions 
> look great, but it also feels me that this is a complicated feature to 
> define. I don't see us finding a good answer to simple questions in a 
> reasonable time frame, such as whether it should be based on code 
> point, legacy grapheme cluster, or extended.

For this level, we can define @text-transform in a simple way and satisfy the simple use cases, such as the transform from small kana to normal kana. It does not need to be so complicated that it's hard to define.

> I agree with John's general principle too. I see defining some i18n 
> values first and then try to look for general @rule in future is a 
> good incremental approach.

This is the exact *opposite* of what I was proposing as a general principle.  Rather than adding what you describe as "i18n values", we should try to generalize features where possible, so that authors can effectively define their own values.  The @text-transform rule is just one example of this and Florian lists many small-use-case examples in his proposal.

It's very hard for the WG to assess whether proposed solutions to internationalization problems are correct, complete or really necessary (e.g. discussions of Armenian numbering schemes on www-style in Feb. 2009).  Basing solutions on actual usage allows us to avoid defining features that are never widely used in practice but widely implemented simply to satisfy the requirements of a given spec.

Regards,

John Daggett

Received on Monday, 12 December 2011 09:17:34 UTC