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


[Koji Ishii:]
> 
> Oh, I missed this one before sending the last mail, sorry about that.
No worries, that was my bad. I'll just answer to this response if that's
OK.
> 
> > Following up on this it seems I'm misunderstanding the problem i.e.
> > we're not really standardizing what one particular engine is doing at
> > the moment - good!
> 
> Wonderful to hear that, thank you.
> 
> > - but we are defining a solution so as to prevent some early adopters
> > from depending on this engine. Said solution derives from work in
> > progress at Unicode; moreover, some content creators expect that
> > whatever content they produce that conforms to our draft will be
> > stable i.e. future UTR50 implementations will not conflict with
> > content.
> 
> I don't think the last part is true. The spec clearly says "we will be
> tracking changes."[1]

You said we resolved to do this to help publishers produce content that does 
not depend on some specific engine, right? And these publishers were happy
when we did. Are they going to be happy when these changes we are tracking 
invalidate some of their content? If they don't care about tomorrow's engines 
rendering today's content differently then I don't understand what problem we're 
trying to solve by hosting this snapshot; if, on the other hand, these publishers 
do expect the content they are producing today to render the same in future engines 
that conform to css3-writing-modes and UTR50 then I do not understand how making 
our own copy of UTR50 fulfills that expectation. Unless we plan on ignoring those 
UTR50 changes that would break existing content. As the latter would amount of 
forking a Unicode spec and that seems a horrible idea I want to make sure I
understand why we're doing this. I clearly thought I did at the time; I no longer
do.

> 
> Well, "some" may be true because not everyone reads specs. Could be "many."
> But as I wrote in my previous mail, we could work on versioning scheme and
> define how to migrate old contents to new one with some transition period,
> if the WG agrees with it.

This is something the WG may do between levels of a spec. We do not and should
not version between drafts. That is the responsibility of whoever wants to implement
them. 

> 
> 
> > If so, that still seems dangerous
> > for all the same reasons. I do not think it is wise to have our own
> > UTR50 fork, however temporarily that may be; *especially* if we know
> > some publishers mean to treat our *draft* and the UTR50 snapshot
> > contained therein as a standard. This sounds confusing, if not
> > misleading. I would not want us to support such an expectation without
> > explicit agreement from our Unicode partners.
> > And if we have such agreement then I really don't understand why we
> > need our own copy...?
> 
> Here's a screenshot of e-book readers today[2] -- they're not CSS-based, but
> I hope you can see how orientations vary by readers. Contents today is very
> low in volume, but we expect tens of thousands of contents being created in
> the coming 6 months, and authors need something to rely on. Does this
> explain the need to have a snapshot?

It explains why we need UTR50 and css3-writing-modes. It does not explain why 
we need a copy of UTR50 into our own draft. 

> 
> Now, please allow me to ask questions to make sure if I understand you
> correctly, because this one seems to be especially important, and I can't be
> confident on my English skills. Sorry for bothering.
> 
> 1. You may be ok if temporarily -- temporarily do you mean by the final of
> UTR50, correct?

'However temporarily that may be' means no, I'm not OK with keeping a copy of
UTR50 in our own specs at all. I don't think we should copy/paste other specs or 
modules we depend on into our own. 

> 
> 2. You may be ok if we don't have to support such an expectation, or if we
> have explicit agreement from our Unicode partners. Correct?

I am saying it is up to Unicode to define UTR50 and indicate whether it is stable 
enough for implementation by publishers or anyone else; we should not be the ones 
saying or implying that imo. Note that I'm not sure we are doing so; but that is 
what I am *perceiving* from your explanation i.e. we do this so publishers who want
to produce e-books today have a one-stop spec to work with. I have a hard time 
assuming said publishers do not also expect future css3-writing-modes drafts - and 
thus UTR50 if we carry that along - to be backward compatible with their content.

> 
> 3. I didn't understand what the "such an expectation" is. Did you mean if we
> can come up with good wordings to make sure what we have in the draft is
> temporarily until UTR50 becomes final, final UTR50 is very likely to have
> different values, and support for the current table will be deprecated in
> future?

I am saying css3-writing-modes should not set any expectations about UTR50's 
completeness or stability, or confuse anyone about the dependency of one spec
on the other by including a copy that may or may not be up to date. 

> 
> 4. Does "explicit agreement from our Unicode partners" mean we get explicit
> agreement from Eric, the editor of the UTR50, to have a snapshot in our
> spec?

Er, you mean you haven't asked? Yeah, assuming there ever is a good reason to
snapshot some other standard body's spec into our own I think we should ask...

> 
> 5. Assuming 3 and 4 are correct, allow me to double-confirm; are they OR? I
> mean, you can live with either, or do you require both?

I am trying to understand why we want to have a snapshot of UTR50 in a CSSWG
draft. I do not understand the need or benefits. I do see plenty of potential
downside.

> 
> [1] http://dev.w3.org/csswg/css3-writing-modes/#vertical-orientations

> [2] http://twitpic.com/a180ys

> 
> Regards,
> Koji

Received on Friday, 29 June 2012 23:37:44 UTC