RE: [css3-writing-modes] vertical orientation and UTR50


[Koji Ishii:]
> 
> Can I ask then what authors should do today? The question we were given at
> Hamburg was, do we want them to create tens of thousands of HTML/CSS files
> based on WebKit's implementation, or do we want to publish our own table.

I don't understand this argument at all. Because some early adopters
have no qualms about taking a hard WebKit dependency we should align with
this implementation even though it already diverges from where Unicode 
is going ?
 
You can't spec early adopters out of doing anything. Your job as editor
is to specify a solution for everyone else. Forking our own bits
of Unicode to placate some early adopters is absolutely not an option imo. 
Publishers are free to take any dependency on WebKit they like; but they 
simply cannot count on Unicode or W3C pre-emptively declaring that choice 
to be conformant. 

Now, were we to reach a point where multiple browser implementations converged 
and handled the same content in a compatible manner *AND* UTR50 diverged from
them then you'd have a somewhat reasonable rationale for *considering* something 
like this as an interim spec fix. But even then, what would it solve? We *cannot* 
fork Unicode. 

And when it comes to Unicode, content is not just web pages. Having browsers 
process Unicode vertical orientation one way while other Unicode processing 
software - e.g. operating system libraries, word processors, formats such as PDF - 
does it differently is too painful to contemplate.

> 
> I assume you're not recommending WebKit given recent discussion on mobile
> web. 

This is a standard WG. Our job is not to recommend WebKit, Trident, Presto or 
Gecko; our job is to recommend what all these and others should do for the
web, not just the 'mobile' web. 

> I also assume you don't like UA dependent, which I originally
> proposed. I can't see what your answer is.

Early implementations will almost always have UA-dependent behavior, 
and early adopters will come to depend on some of these. Our job is to 
minimize - if not eliminate - UA dependencies from future content and
implementations. Diverging from another standard body's ongoing work
due to a single early implementation is not a good way to achieve that.

> 
> If I understand correctly, our ultimate goal is to maximize the
> interoperability of the Web technologies, so that authors can trust us. So
> that later implementations can enjoy existing contents. So that users have
> maximum freedom to choose their favorite browsers to view contents.

What existing content are we talking about? 'What a lot of content would look
like if it conforms to the last WebKit nightly' does not qualify as 'existing 
content'. If some ebook publishers want to depend on WebKit's implementation, 
they're welcome to. If that turns out to be incompatible in the future then 
they'll need to deal with the legacy they chose to create. Such is life.

> 
> I don't think the resolution does anything wrong to the goal.
> 
If the DWrite team builds UTR50 support and I can't also conform to your draft 
without special-casing their work I'll have to disagree and formally object.

So. If you think WebKit's current support should be the standard then you need to
convince the folks who write UTR50 to agree. Pretending they already have by 
maintaining your own copy is not the way to go.

Received on Friday, 29 June 2012 18:51:20 UTC