Re: [css3-writing-modes] auto text-combine requirements

Oops, my apologies for my typo.

"argue automatic text-combine" should have been 
"argue against automatic text-combine

A revised version (with some other minor fix) is shown below.

Cheers,
Makoto
---------------------------------------------------------------------------------
I think that auto text-combine should not be mentioned in the current 
writing mode spec.

>A few argued it should be, while most think it can be in future levels. 

I would argue that it should not be included even in future levels.
It appears that the biggest motivation for auto text-combine is to make
authoring easier.  However, book publishers tend to prefer very fine control
and argue agaimst automatic text-combine, probably because they care
house rules and even want to make decisions on a case-by-case basis. 
Meanwhile, newspaper publishers (or those who do not want to spend time)
tend to like auto text-combine for automating authoring.  I think that
auto text-combine should be left to CSS authoring environments rather
than CSS rendering engines: in other words, authoring should generate 
text-combine when the author would like to apply some automatic rule 
to an entire document.  This approach makes the design of CSS easier 
and also makes browser implementations easier.

Somebody might provide very good reasons for incorporating auto
text-combine in the future, but I do not see any such reasons at present. 
We should not assume that we have to incorporate auto text-combine 
in the future.

At this stage of the game, it is important to make text-combine 
mature as soon as possible.  It is not a good idea to make it
complicated only for a questionable extension in the future.

Cheers,
Makoto

> We had some discussions in Japanese ML about the requirements for auto text-combine mentioned in the current writing modes spec[1].
> 
> Whether it's required in Writing Modes Level 3 or not (could be considered in future levels) still splits. A few argued it should be, while most think it can be in future levels. But to make sure we are talking about the same thing, we had some discussions about its requirements. So, please consider this mail to help us understand the requirements better, not to push the feature into the current spec.
> 
> The feature should have two options:
> 1. The maximum number of characters to apply text-combine automatically
> 2. The class of characters to apply
> 
> For the class of characters, it's a choice between the two options:
> 2.1. Digits only
> 2.2. All narrow letters and punctuation
> 
> The definition of 2.2. should be defined in more details as we go further, but for now I think all narrow as defined in UAX#11[2], and all L*/P* categories would suffice.
> 
> The definition above matches to what Adobe In Design has today.
> 
> There's another opinion that should also be supported, which is about how to or whether to fit within almost 1em box.
> 3.1. Don't do anything
> 3.2. Allow use of half/third/fourth glyphs if available in the font
> 3.3. Scale to 1em box if the width exceeds some specified limits
> This isn't a feature In Design doesn't support today in its auto text-combine feature today (supports 3.1. only), but we might want to, because In Design is a software for authors and authors can do anything after applying the feature, while in CSS the feature can be the one user can apply. This part I believe is still unbaked well enough and we need more discussions.
> 
> It might sound like it's still rough idea, but I hope this helps us to think about the feature.
> 
> 
> [1] http://dev.w3.org/csswg/css3-writing-modes/#text-combine
> [2] http://unicode.org/reports/tr11/
> 
> 
> Regards,
> Koji

Received on Sunday, 16 January 2011 13:03:57 UTC