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

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

No, they asked us because they do have qualms and hoped us to give a solution. And we once gave them in May.


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

My job as an editor is to specify a solution the WG agreed and resolved, and I'm doing exactly what I should do, don't I?

Adobe has released the preview version of their software using their own orientations. A few more vendors were in the queue using their own orientations, by fixing what they believe is correct over the WebKit.

Publishers and authors are really in trouble and asked us for a help. They never counted on us.

They asked for a help, and we resolved to help them.


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

We could then deprecate the table and add another value for the final version of UTR50. We could add versions to the syntax. There are many ways to lead gradual move to the final UTR50. Implementers may have to maintain a few tables for a period of time, but it's far better than each implementer having different tables.


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

UTR50 is a foundation. How to interpret, say, Tu or Tr is up to upper layers. Because we have resolved that orientations in CSS should not depends on fonts, it's quite likely that the interpretation will be different from word processors. If they took the same way as CSS, it will bring them back to Word 2.0 level of multi-lingual capability. The goal of UTR50 is still fragile as John pointed out; some people believes it should be designed for plain text as the first priority. If we go that way, again, word processors will not be able to take it. PDF has different orientation mechanism already standardized as ISO.

Consider GDI. It has a default orientation table. UTR50 is a good improvement over it. But no professional software use just GDI to render vertical flow today, because doing so produces only similar results as notepad. The goal of UTR50 is not about to change the situation, but have a common default orientation across platforms and increase the coverage to global.


> > 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'm sorry, I don't understand this. Maybe my wordings were not appropriate, sorry about that. What I wanted to say was, if we tell authors to do UA dependent and let the market to decide, we will have a risk to see what we see today for webkit-text-size-adjust.

I completely agree with you on the job of a standard WG. Users, authors, and implementers are asking for a recommendation to us. What would we recommend?


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

As I said above, it's not single implementation already. And we're not diverging, snapshotting with possible versioning strategy is very different from diverging.

I agree that it's not the ideal way, but if you have any other ways to help authors and implementers, I'd really love to hear. Asking them to wait doesn't help, and I'm pretty sure that it will hit us back.


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

No, you misunderstood. They do NOT want to depend on WebKit, and that's why they asked me to raise this issue at Hamburg. If we can't help them, at that point, they may had to depend on WebKit.

They asked us for a help how they can make their contents to qualify as 'existing content,' and we promised to help. Now are we trying to pull the ladder?


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

I don't know when and what the DWrite team is going to build. If UTR50 is final by the time the DWrite team is going to start writing code, we will have a version scheme to distinguish the final. You could support only final, or support deprecated value as well, it's up to you.

And it's never been my draft, it's our draft. I've never wrote single word that the WG do not agree.


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

I'm sorry if my previous mail was misleading, but I've never said WebKit should be the standard. Ah...and I'm sorry again but I didn't understand the last sentence. We told Eric and Laurentiu that we're going to snapshot, they didn't respond, which is understandable, because I guess we will say so to other groups if we were in the same situation.


Regards,
Koji

Received on Friday, 29 June 2012 20:24:01 UTC