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



On 10/2/13 10:58 AM, "Koji Ishii" <kojiishi@gluesoft.co.jp> wrote:

>Thanks for the reply. I understand what you say, but I often use
>dictionary, so I'm afraid some wording might not be appropriate for the
>context or express what I want to say. It looks to me that sometimes
>you're asking something I replied, so I guess some of my text can't
>really read well. Sorry about my English.

I think your English is totally fine.

>
>You might not agree but to me, it looks like we're very close, but
>different conclusion. I'd like to clarify what's causing that, if you
>don't mind.
>
>> Again, a spec is not some kind of voting contest where we add
>>alternatives
>> every time a few people want things to behave a certain way. Otherwise
>> Microsoft may prefer a third option tomorrow and then we need to add
>>that.
>> Next week Apple may want have a fourth etc. Would the resulting menu of
>> implementation option constitute a standard?
>
>Completely agreed. But in this specific case, Tr is in UTR#50 for 1.5
>years. Microsoft, Adobe, Apple, Google are there. It's been in CSS spec
>more than two years, Mozilla and Opera are there. AH had also reviewed
>from implementation point of view, and we've got only two. Also, both
>makes logical sense to me, so I hope your concern will not be real in
>this specific case.

The length of time something has been in a draft spec does not factor into
whether it should remain in a Recommendation. Nor should it be. Many, many
things stay in spec for 1, 2 or 3 years before changing because it can
take that long for implementation experience to reveal a problem or a
better approach. I am also not aware of evidence that Microsoft, Adobe,
Apple and Google's UTC reps believe the lack of such an option in CSS
Writing Modes somehow compromises Unicode compatibility. I am privately
aware that some of them actually disagree with this.

>
>> Based on John's compelling argument and the opinion of a few experts
>>I've
>> heard from I do not think the fallback behavior is necessary.
>
>Thanks, understood. As the editor of UTR#50, I wish you and people around
>you make feedback to Unicode, but that's not a topic here, let's focus on
>CSS for now.

We will not because we do not believe it's necessary i.e. we do not think
UTR50 is required to change in order for this option to be removed from
the css-writing-modes. It's clear you believe such a hard dependency
exits; on my end I have as of yet found no consensus that this is the
case. Quite the opposite, in fact.

>
>> If they cannot tell the difference then what is the benefit of having
>>two
>> ways to do it, with two sets of testcases etc.? And if the result is
>>the same
>> then picking one is easy: the one that is simplest to code and test
>>because
>> it's the one that will be easiest to get right.
>>
>> If there is zero difference to users and authors, what is the payoff of
>>writing
>> *more* code?
>
>I thought I explained this, so let me try another wording.
>
>No benefits nor changes to users and authors. We agreed on this, right?

We do not need to agree on it for the purpose of my questions; it actually
makes the point of this section even more puzzling, to be honest.

>
>The cost is on the test-writer, true, I agree.
>
>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.

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

  

>
>Actually, when AH requested the UTR#50 behavior, it was considered as
>more code and it was just he was willing to do, so I declined the
>request. After that, another developer said it's actually cheaper for
>him, and it was considered that it's not only him. I took it at that
>point.

We should not impose additional requirements on all implementors because
one of them claimed it would make his life easier. We can only do so if
there is a consensus among them that this is in fact valuable. I do not
see any such consensus here (to say the least…).

Consensus is not about specifying however many versions of a feature as
there are implementors who think of ways to make it work.



>
>Does this make better sense?

No, not really. Sorry.

>It looks to me that our goals are the same, no?

I'm sure there is a level at which they align, if we zoom out far enough
:) Jest aside, I think the goal is the same. But there are many ways to
reach a goal and not all of them are valid or desirable. I'm afraid we
remain in disagreement on the chosen path. We do not need to argue further
until new information surfaces though. Thank you.

>
>/koji
>
>-----Original Message-----
>From: Sylvain Galineau [mailto:galineau@adobe.com]
>Sent: Thursday, October 3, 2013 2:22 AM
>To: Koji Ishii
>Cc: W3C Style
>Subject: Re: [css3-writing-modes] inconsistent handling of 'Tr'
>codepoints in 'text-orientation'
>
>
>
>On 10/2/13 9:43 AM, "Koji Ishii" <kojiishi@gluesoft.co.jp> wrote:
>
>>I have no idea what makes you so emotional. Did I say something
>>impolite or illogical?
>
>I'm sorry; what was emotional? Baffled is not really intended to
>represent an emotion here; I don't understand why anyone would think
>offering implementors multiple ways to do one thing makes their lives
>easier or reduces compatibility issues; or why we make CSS more
>compatible with Unicode when we say it's conformant to take an
>incompatible option. Those things just don't add up. And every attempt to
>clarify the gap just ends up with a re-iteration of the same confusing
>assertions. So yeah, it's baffling. There is nothing emotional about it;
>John, you and I just appear to be stuck in a pattern and I can't figure
>out a way out of it.
>
>So nothing impolite at all; but illogical, sure. I've pointed out quite a
>few things I find illogical.
>
>>
>>Your opinion is not to have two options, I understand that, but which?
>
>Based on John's compelling argument and the opinion of a few experts I've
>heard from I do not think the fallback behavior is necessary.
>
>>
>>1. We accepted John's proposal to move text-orientation:mixed to
>>Unicode two years ago.
>>2. John then said Tr is hard to implement for him, tiny tailoring will
>>make it much easier.
>>3. Another implementer said John's proposal is hard for him, requested
>>to stick to Unicode.
>>
>>Both are the same arguments, just opposite, and the numbers of
>>supporters are coincidentally the same as of today.
>
>Again, a spec is not some kind of voting contest where we add
>alternatives every time a few people want things to behave a certain way.
>Otherwise Microsoft may prefer a third option tomorrow and then we need
>to add that.
>Next week Apple may want have a fourth etc. Would the resulting menu of
>implementation option constitute a standard?
>
>>
>>I agree with you as general rules, but in this specific case, I do not
>>see a good way to pick one, nor anything anyone would lose by allowing
>>both.
>>
>>John already mentioned that users and authors will not know the
>>difference.
>
>If they cannot tell the difference then what is the benefit of having two
>ways to do it, with two sets of testcases etc.? And if the result is the
>same then picking one is easy: the one that is simplest to code and test
>because it's the one that will be easiest to get right.
>
>>
>>You're right implementers need to spend time on choosing which
>>implementation s/he would take, but the cost return will pay the time
>>s/he spend to choose.
>
>If there is zero difference to users and authors, what is the payoff of
>writing *more* code?
>
>>
>>I can write a test that both implementations can pass. I haven't done
>>it yet, but I know how to do it and I'm hoping to write it in some TTWF.
>>
>>Well, if you're talking only about general rules but not this specific
>>case, I completely agree with you, sorry that this discussion must be a
>>noise to you.
>
>If it was noise to me I'd completely ignore it. I don't understand what
>you and John are jammed on; I've chatted with people more knowledgeable
>than me about this topic and thus far they've been unanimously as
>confused as me. Thanks for trying though...
>
>>
>>-----Original Message-----
>>From: Sylvain Galineau [mailto:galineau@adobe.com]
>>Sent: Thursday, October 3, 2013 1:06 AM
>>To: Koji Ishii
>>Cc: W3C Style
>>Subject: Re: [css3-writing-modes] inconsistent handling of 'Tr'
>>codepoints in 'text-orientation'
>>
>>
>>
>>On 10/2/13 8:42 AM, "Koji Ishii" <kojiishi@gluesoft.co.jp> wrote:
>>
>>>> >It's implementers and implementers. On one side, two implementers
>>>> >said it's hard, so we added option B. On the other side, two
>>>> >implementers said they'd favor option A. One of them said he has
>>>> >already implemented option A.
>>>> 
>>>> I do not think your role as editor is to log every implementor
>>>>preference and spec it as an  alternative. It is a very bad idea for
>>>>specs to offer implementors equally conformant option  as this
>>>>results in incompatibility for content and authors.
>>>
>>>I completely agree with your statement on the editor's role, and the
>>>second sentence as well.
>>>
>>>This is the case where all agreed that the incompatibility caused by
>>>the difference is very subtle, almost unnoticeable, and will be
>>>completely gone when user use the right fonts.
>>
>>If this is such a small unnoticeable issue then specifying multiple
>>implementation options is massive overkill. I also fail to understand
>>why we'd want to suggest fallback behavior if we believe users will
>>always have the right font in the not-so-distant future.
>>
>>One more thing: that someone already implemented one of these options
>>is not a valid motive to include it in the spec or keep it there. We do
>>not create implementation forks in a standard because someone did
>>something at the draft stage.
>>
>>
>>>
>>>The costs to implement vary by underlying architecture. For one
>>>architecture, option A is much cheaper, while for another
>>>architecture, it's opposite.
>>
>>The cost of UAs doing the same thing differently should be multiplied
>>by all the authors who will have to deal with it. You should consider
>>the overall cost of varying implementations, not just the cost to the
>>tiny number of people who implement it.
>>
>>Also, if we believe implementors to be sensitive to implementation cost
>>then it's entirely reasonable to assume they will overwhelmingly favor
>>the option that does not include extra work i.e. they will not
>>implement the fallback behavior. That is also a good reason to question
>>its necessity.
>>
>>>
>>>Having two options help both implementers, while we lose almost zero,
>>>compatibility in the real world isn't sacrificed, only tests might
>>>fail, and some does care passing tests.
>>
>>I completely disagree. Having multiple options to choose from does not
>>help implementors, not is it compatibility-neutral. It will  also
>>require more test cases since you need a set of tests for each
>>conformant alternative. It is more work for everyone; yet you argued
>>earlier that this is an subtle unnoticeable problem. Why would we want
>>to increase the cost of dealing with a minor issue?
>>
>>>
>>>That is why I'm asking, why John thinks we should remove option A.
>>
>>I think we have reached a pretty complete communication failure at this
>>stage, since so many of your arguments rely either on known design
>>anti-patterns or incoherent positions. I'll admit I'm 100% baffled here.
>>
>>>
>>>/koji
>>>
>>
>

Received on Wednesday, 2 October 2013 19:58:33 UTC