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



On 10/2/13 8:05 PM, "Koji Ishii" <kojiishi@gluesoft.co.jp> wrote:

>Thank you a lot, I think we're narrowing down the point.
>
>> >The benefits are for implementers. "The one that is simplest to code
>> >and test" is different. Neither side says "I like this so I want to
>> >write more code." Both sides say "this is much cheaper and simpler for
>>me."
>> 
>> I do not understand how an option that requires an explicit check and a
>>possible fallback
>> is cheaper or simpler than an alternative that doesn't mandate either.
>>But let's put that
>> aside. If these two implementation approaches do produce the same
>>results in all cases
>> then why do we no need to specify them? Why should we constrain those
>>who prefer a 3rd
>> or a 4th way to one of these two? As long as the *valid result* is
>>clearly specified there
>> should be no need to set requirements on how it ought to be
>>implemented. We don't define
>> *how* implementors should do things, we standardize *what* they should
>>do.
>
>The spec is not how to implement, what results it should produce.
>Although both John and I said it's almost the same results, as John said,
>there are a few code points that might be affected in some fonts. John
>and I agreed that that difference is subtle, and tailoring is fine for
>users and authors.
>
>So there are two different but both valid results. My proposal is to
>accept both results.

We are back to John's point all along: allowing different results means
allowing incompatibility which is not something a standard should
deliberately do without a very strong rationale. (That someone somewhere
already did it that way is not and has never been a proper rationale to
specify anything, in particular).

>
>But then it looks like your key discussion is what you put aside. You're
>right, I guess I didn't explain much details about that, so let me try.
>
>> >So the payoff of having two options is writing less code for everyone
>> >we know as of today, without adding any more codes to anyone. If we
>> >pick one, the other side has to write more code.
>> 
>> One of these options clearly requires more code than the other, Koji;
>>so it can't be about
>> everyone writing less code. So I think what you really mean is that by
>>having both options
>> you're saving *someone* some work because they've already taken this
>>approach in their
>> code? That is not a valid concern for a draft specification. This is a
>>private concern of this
>> one implementor.
>> 
>> But even if someone's existing code were a factor, I believe that
>>whoever already
>> implemented the fallback approach would be *removing* code, not writing
>>more of it. It's
>> true that it's new extra work for them but I don't buy they'd be worse
>>off when done.
>
>The first portion is right, thank you for understanding. The problem here
>is that that someone is in different layer, because Unicode is underlying
>layer of CSS. Let's say, someone in Skia (or CoreText or DWrite) team
>considered UTR behavior is important for drawing label controls and
>implemented it in Skia. This portion you're right that it's an additional
>code, but it's out of control for UA implementers.
>
>Now a developer came in to implement a UA upon the Skia. It exposes
>vertical text drawing API with a flag:
>
>enum VerticalOrientation { mixed, upright, sideways_left, sideways_right
>};
>
>If CSS allows UTR-compliant results, all s/he needs is to pass the
>computed value of text-orientation to this API. Done, as little code as
>possible, no splits, fast.
>
>If he needs to produce exactly the same result as John's proposal, he
>needs:
>1. Have a table of code points of Tr
>2. Every text run must be split into text without Tr code points and text
>of Tr
>3. When drawing Tr text, it must pass "upright" to the API
>
>It's not a private concern; all developers using the API have to write
>this additional code, and all such UA must pay the performance cost to
>split text runs.

What you are talking about most definitely sounds like a level of web
engine implementation details no spec should get into. The spec's job is
to define how implementations pass and fail for the feature's range of
inputs; what kind of APIs the feature may or may not be wrapped into
internally is implementors' concerns.

>
>You may, instead, ask Skia developers to add a flag to produce the same
>result as CSS specifies. Then there's no additional code for UA
>developers. But Skia team is in trouble by getting two different
>requests; one wants UTR-compatible behavior because the group agrees with
>UTR, the other wants tailored results because the group does not agree
>with UTR.
>
>Is this good enough to understand, a large amount of developers must
>write more code if CSS does not allow Unicode-compatible behavior?

I'm afraid you've confused this even further. One moment there is no
difference and either approach produces the same results, which begged the
question why we needed two; the next the differences are so obvious the
spec needs to concern itself with hypothetical implementation approaches
and recommend several that may produce different results.

And you still stick to the UTR compliance requirement yet propose spec
prose that implicitly makes both compliance with UTR or the lack thereof
conformant.  

You've made a valiant attempt and I thank you for that. But we're not
making progress; we're going in circles. So let's leave it at that for now.

>
>/koji

Received on Thursday, 3 October 2013 04:00:35 UTC