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

Hi Koji,

I'll say it again, UTR50 is the basis for default vertical orientation
of characters in CSS. However, the specifics of things like font
fallback on the web are specified in CSS, not in Unicode.

Let's get back to the reasoning behind the need to allow make optional
treatment of 'Tr' codepoints.  It's optional behavior, so that makes
orientation decisions inconsistent across user agents.  That's bad. 
Making it normative would eliminate that inconsistency but it does not
seem at all necessary, since fonts used for vertical text rendering
support vertical alternates for these codepoints.  In the fonts I
looked at, I only see one or two codepoints that would be affected by
this fallback behavior.  So common practice would suggest that this
fallback behavior is largely unnecessary.

If you think this behavior is important I think you need to
demonstrate more clearly the practical use this fallback has.  And why
it's important to allow the inconsistency implicit with optional
behavior.  What was the reasoning behind the developer who told you it
was important?  That's what is important to understand here.

Cheers,

John Daggett

More on UTR50, Unicode and CSS:

> 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.

Koji, this is an informative property rather than a normative one, as
the conformance section of UTR50 quite clearly states.  It establishes
a reasonable default for vertical character orientation but applications
using this data are the ultimate arbiters of behavior, as noted in 
the conformance section of UTR50:

http://www.unicode.org/reports/tr50/tr50-11.html#conformance

# The property defined in this report is informative. The intent of
# this report is to provide, in the absence of other information, a
# reasonable way to determine the correct orientation of characters,
# but this behavior can be overridden by a higher-level protocol, such
# as through markup or by the preferences of a layout application.
# This default determination is defined in the accompanying data file,
# but in no way implies that the character is used only in that
# orientation. 

The Vertical Orientation property is an informative property and CSS
is using it as that.  There's no strict compliance requirement, nor do
I think what I'm proposing violates the spirit of the property as
defined.  I don't object to anything in the UTR50 spec, nor do I think
anything was done "poorly". I simply think CSS should use the data in
a practical and efficient manner.

Koji, if you disagree with what I'm suggesting we do in CSS I think
you need to justify it at a technical level rather than trying to
justify it only in terms of spec compliance.


----- Original Message -----
From: "Koji Ishii" <kojiishi@gluesoft.co.jp>
To: "John Daggett" <jdaggett@mozilla.com>
Cc: "W3C Style" <www-style@w3.org>
Sent: Wednesday, September 25, 2013 11:59:10 PM
Subject: 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 23:50:30 UTC