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

> the fallback behavior is unnecessary for CSS

So you want to tailor UTR#50 for CSS, correct?

I'm fine to allow tailoring, but I don't think it's appropriate to
prohibit UTR#50 compliant implementations in CSS. In all other specs in
CSS, we allow tailoring from Unicode specs, but no other CSS specs I know
denies and prohibits what's written in Unicode. All over the time, since I
joined CSS WG, I think it was you who told everyone that we should follow
Unicode as much as possible, and I'm doing that here.

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

As a UTC member, there were discussions on Tr, somewhat similar to what
you say, multiple times, and UTC resolved the revision #11 to publish as
it is today. UTR is a technical note which technically speaking can change
anytime, but given its purpose, UTC wants UTR#50 to be very stable and
values do not change over time at least for currently assigned code
points. 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.

The spec stability requirements are different for Unicode and W3C, so I'm
fine for CSS to allow tailoring. But I don't agree with prohibiting what
Unicode defines.

/koji


On 9/25/13 2:25 PM, "John Daggett" <jdaggett@mozilla.com> wrote:

Koji Ishii wrote:

> This optional behavior is what UTR#50 defines:
>> Tr Same as Tu except that, as a fallback, the character can be
>> displayed with the code chart glyph rotated 90 degrees clockwise.
> 
> So if you think this behavior is unnecessary, you need to feedback to
>UTC.
> The members at UTC raised a concern because CSS does not allow the
> behavior as defined in UTR#50. The need for allowing this optional
> behavior is to allow an implementation that follows UTR#50.

If your intent was to specify CSS behavior via UTR50 I don't think
that's really appropriate.  I agree with the statement, the character
"can be displayed".  But Unicode is a character standard, not a font
and text engine standard.  You need to separate the two.

Given actual fonts and real world conditions for the web platform, I
don't see an actual need to require or optionally allow such fallback,
since OpenType functionality and actual fonts already provide the
necessary alternates.  In some closed-end non-OpenType environment,
the Tu/Tr distinction might be useful, but since fonts already support
both Tu and Tr codepoints, the fallback behavior is unnecessary for CSS.

Just in case this wasn't clear, I see no issue with Unicode here, I
only see an issue with what you've specified for CSS.

Could you explain more clearly under what conditions this fallback is
needed?  What content rendered with what set of fonts makes this sort
of fallback desirable?

Regards,

John Daggett

Received on Wednesday, 25 September 2013 05:55:46 UTC