RE: [css3-writing-modes] vertical orientation and UTR50
Koji Ishii <kojiishi <at> gluesoft.co.jp>
2012-06-30 08:53:06 GMT
> > 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.
Yes.
> 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;
You're right that it's not ideal. There are two issues here; interoperability and longevity. We don't have
either today.
Both are important, but by looking at the reality, they understand HTML/CSS3 is not rock solid yet.
Underlines are drawn on the left so they use borders instead. Text-combine is fragile so they use spans
today, or even images. Most renderers do not support Unicode IVS yet so they use images for some
characters. Because of these issues, they do understand longevity is hard, and they understand that
sometime in near future, they have to upgrade all the contents, once or twice or even more.
But interoperability is a separate issue. Adobe has released its prerelease version with their own
orientations. Amazon and Kobo showed their sneak preview on their sites last week. Many implementers
have provided their evaluation versions with their own orientation too, each of which differ from each
other. Authors had to create one file for each implementation before Hamburg, and they couldn't go with that.
So the solution they need is to resolve interoperability, but it does not necessarily resolve longevity.
> 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.
I guess I found one different view we have here. When we say "future," I guess you're talking about future
after UTR50 goes final, right?
I have no idea when it happens. Maybe in 6 month. Maybe more. I wish it be quick, but I don't want to count on it,
and I expect there will be more implementations before UTR50 goes final. We have different view here,
haven't we?
Let's say one implementer took draft #5 and fixes they wish. A couple of months later, another implementer
took draft #7 with their favorite fixes. Some implementers may ignore UTR50 because it's still a draft.
They will be then not interoperable. I wish someone gives a guideline for what to do before UTR50 goes final.
That someone could be anyone. Not necessarily the CSS WG. But we're the organization of interoperability
of web technologies, and we'll need to give one when UTR50 is final anyway because upper layer must define
interpretations of values, so it's ideal if we can give a temporal guideline earlier.
> > 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.
Ok, it's up to the WG. I wish we had, and I'll probably propose anyway, because orientation is too
fundamental compared to other properties, but I'll follow the WG decision as I always do.
I understand the Web is more about live and not much about longevity. EPUB3, KF8, and other packaging
formats care more about longevity, and they have versioning scheme built-in, so they're fine. I'm
expecting some e-books go the Web too, but Web is probably easier to update contents and easier to ask users
to upgrade their browsers.
Versioning scheme is a nice-to-have for me, I agree that we can update the table without it.
> 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.
It may come to when we expect UTR50 goes final, and when we expect authors start creating files. For UTR50, I
have no idea, but the next UTC conference is 30th Jul, and I hope you agree that it won't go final by then. The
next UTC is 5th Nov. Maybe or maybe not. The next is 28th Jan, 2013. Maybe, who knows. Remember, when we
started working on UTR50, everyone thought it's 3 months of work. One year has passed and we're still in the
middle of the road.
And the deadline I was given was June, 2012. I hope you understand that there's a clear gap between the two,
and I'm more than happy to hear any proposals to make implementations interoperable during the period.
> > 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.
I agree that we shouldn't. But we're in the conflict of priority.
They are not asking to have a snapshot, they're asking for the interoperability, and we're the world's best
organization that makes the web technologies interoperable.
We have to choose either one of these; make a snapshot, disregard the request for interoperability, or come
up with a new idea.
I hope the WG does not give up the interoperability so easily. I also hope that the WG would not pull the ladder
once promised, after the deadline is over.
> > 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.
I don't disagree with you again. I completely agree with you that this is a hard choice. The problem is, not
snapshotting will end up with un-interoperable chaos and possibly near-future implementations will be
kicked out until UTR50 goes final and everyone finishes migrations. This period could be from 6 months to
years. This is not good, and snapshotting is not good either. Which would we take?
I also agree that your concern is valid that we do not want them to have such expectations. We could do that
whatever we can to minimize that, and remember, it's always the WG to decide, so we can disregard even if
they had such expectations. So while I agree with the concern, I think it's workable.
The problem again is which bad way is a better choice for us.
> > 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.
Well, if authors/users expectations are the real problem, couldn't we reduce the risk by adding more wordings?
> > 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...
I told them. But I also understand it's probably hard to make an official answer, so I didn't ask them to
answer. Remember two years ago when EPUB guys came in, we didn't answer. We said this and that, I remember
someone said they should take a copy of the CSS specs, and didn't tell them the WG conclusion. It looks very
logical and reasonable to me. If EPUB needs something we can't provide, they should take the risks by
themselves. Now that several technologies using CSS are asking us for the interoperability of CSS. We
publicly said we'll help them. I'll follow to whatever the WG decides, but I think this is a very critical
decision for the WG.
> > 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.
Ok, I completely agree with you that it has potential downsides. Is this mail good to explain benefits, and
downsides of not doing so?
Regards,
Koji
RSS Feed