RE: [css3-writing-modes] inconsistent handling of 'Tr' codepoints in 'text-orientation'

You really surprised me by saying that. Unicode decided to work on UTR#50 because you asked for it, in the name of the CSS WG. UTC put high priority on it and spent a lot of time because CSS WG requested to do so. Other applications are also in the scope, but CSS WG is the primary scope for UTR#50. Therefore OpenType fonts are in the scope. UTR#50 is designed by experts of fonts and layout in UTC, and the use in CSS is always in UTC's mind. The chairs and members asked me several times if UTR#50 taking longer than originally planned was troubling CSS WG.

And now you're saying, UTC does not know fonts and layout well enough that CSS WG should ignore what UTC resolved?

As I said several times already, I do not want to repeat hours of discussions done at UTC in this CSS mailing list, without people who spent hours on UTR#50.

If you think they defined it poorly, and you want not only tailor UTR#50 but also want UTR#50-compliant implementations non-compliant to CSS, please talk to UTC. It's not me who defined UTR#50, it's UTC, so objections should go to the right people.

I'm fine to allow tailoring Unicode specs, but I cannot agree with making any Unicode specs non-conformant to CSS specs for whatever reasons without UTC's consensus.

So, reasons don't matter to me. If you think UTC is wrong and want to prohibit what they resolved, please talk to UTC. Doing "UTC is wrong" discussions at www-style is wrong.

Or, another way is that, if CSS WG resolved to do so as WG resolution, I can follow the resolution as an editor of the CSS spec. I believe what you're asking for here is more than just personal opinion, and requires the WG resolution.

/koji

-----Original Message-----
From: John Daggett [mailto:jdaggett@mozilla.com] 
Sent: Wednesday, September 25, 2013 3:46 PM
To: Koji Ishii
Cc: W3C Style
Subject: Re: [css3-writing-modes] inconsistent handling of 'Tr' codepoints in 'text-orientation'


Koji Ishii wrote:

>> the fallback behavior is unnecessary for CSS
>
> So you want to tailor UTR#50 for CSS, correct?

As I've said several times already, I see no problem with what's defined in Unicode.  CSS doesn't need to customize or tailor it.  The Vertical Orientation property was never intended as a single, absolute definition of character orientation, merely as a good default.  Which is why the default value of 'text-orientation' should base orientation upon that property.  But authors will still need to use explicit markup to set the orientation in situations where the default doesn't match the needs of their content.

We should not view the Vertical Orientation property as a definition of OpenType feature fallback.  Unicode defines general character usage and UTR50 makes useful distinctions between sets of codepoints in the case of the Tu and Tr values.  How that information is used for the web platform is the domain of CSS, not Unicode.

>> Could you explain more clearly under what conditions this fallback is 
>> needed?
> 
> As a CSS WG member, the whole purpose is to follow what Unicode defines.

Koji, could you please explain at a practical level why it's necessary to define fallback behavior for Tr codepoints when fonts already provide vertical alternates for almost all the Tr codepoints already?
You said a developer was interested in implementing this behavior.  I think it's important to understand *why* they thought that was important, since I'm guessing they were motivated by a practical set of conditions.  What environment, what set of content and what fonts required such fallback?  Understanding this is much more important than quibbling over what the boundaries of Unicode and CSS specs.

Ultimately the web platform is based on a whole slew of standards that need to work together to render text in an efficient and consistent manner.  Given that fonts already provide the alternates required for displaying Tu and Tr codepoints, you're arguing for inconsistency by defining optional fallback behavior in a situation where it's not really necessary.

> The purpose of Tr, as I understand, is for implementations to work 
> well not only with today's fonts but also with fonts decades later.
> Other members may say differently though since there were several 
> discussions over time, but after all those discussions, UTC resolved 
> to keep Tr in the revision #11.

Adding optional complex fallback is not forward-looking, it's adding a burden on implementations and introducing inconsistency across user agents, neither of which sounds like a good thing.

Cheers,

John Daggett

Received on Wednesday, 25 September 2013 14:59:41 UTC