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 06:46:50 UTC