W3C home > Mailing lists > Public > www-style@w3.org > June 2012

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

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Fri, 29 Jun 2012 04:31:05 -0400
To: John Daggett <jdaggett@mozilla.com>, www-style list <www-style@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0D5E51CF72@MAILR001.mail.lan>
> The current draft of the CSS3 Writing Modes spec defines the values for the
> 'text-orientation' property based on the proposed vertical orientation properties in
> Unicode [1].  Specifically, 'mixed-right' is defined to be based on the mixed vertical
> orientation property value
> (MVO) and 'upright' is based on the stacked vertical orientation property value (SVO).
> This makes sense and I completely agree with this.

Great to hear that, thank you.


> However, in section 5.1.1 [2] the spec defines these in terms of variations on the
> proposed UTR50 versions of these properties, using the terms MVOsimple and
> SVOsimple.  It links to a data file on csswg.org which contains values that are
> different from the current data file associated with Draft 5 of UTR50.  Elika says
> these are edits that have already been generally agreed upon but have not yet been
> published in a UTR50 draft.
> 
> I really, really, really don't like the idea of publishing our own variation of UTR50.
> Right now there's considerable discussion in Japan via twitter etc of UTR50 [3] and the
> role of MVO/SVO in vertical text layout.  I think some of this discussion may just be
> misunderstanding about the intent and utility of UTR50 data but I think part of it may
> be valid criticism that leads to changes/restructuring of the data.  I think we should
> let that discussion influence definition of UTR50 and not introduce more noise into an
> already noisy discussion.  The proper place for discussion of these details is in the
> Unicode forum for UTR50, not on www-style.

It's not a variation, it's a snapshot. It's true that fantasai and I have a different table at wiki, and that there are a lot of conversation going on, but the data in the ED is based on the draft #5 plus only changes that were discussed with Eric and Microsoft. It's not from our table on the wiki. I'm sorry if this wasn't clear, I hope this clears some of the concerns you have. Neither fantasai nor I have intention to use our ED/WD to influence UTR50 at all, and we fully agree with you that doing so is really a bad idea.


> I realize that applications are being written that diverge in behavior [4] and that some
> sort of convergence is necessary for interoperability.  But given the current state of
> the discussion I think the only way to draw matters to a conclusion is to wait for those
> with opposing views of UTR50 data to resolve their differences.
> Publishing a CSS version of the data will not aid resolution.

As I wrote above, it's not a CSS version. We agreed that waiting further will make things worse, and I hope you agree that a snapshot is necessary to avoid spreading CSS files without interoperability, this paragraph is just worry about a variation, right?


> It would be much better for this part of the spec to define the behavior of 'mixed-right'
> and 'upright' given the specific values of the MVO/SVO properties defined in UTR50
> (i.e. R, T, Tr, Tu, U). The spec contains the wording below but in an informative note
> that doesn't fully explain how the logic is to be used:
> :
> Proposed replacement:
> :

I'm not sure if I understand your concern here very well, can you explain a bit more please?

I hope you agreed to take a snapshot by now. Assuming so, is your concern:

A. The definition of the derived properties is not normative.
B. The definition of the derived properties doesn't define what HO/VO are.
C. We should not make derived properties but use a snapshot of MVO and SVO directly.
D. Text is easier to understand than pseudo-code.
E. HO should not be used to define derived properties or behavior.
F. Something else.

Which one, or a combination?

A and B are easy to resolve, I'm fine to follow whatever the WG thinks good.

For C, I'm in favor of having derived properties at least until UTR50 goes final, because how to interpret UTR50 is very easily misunderstood, and its definition is still fragile. Derived properties help people to understand the same way and result to the same implementations, and is better prepared to future changes in UTR50.

For D, I have a mild preference to pseudo-code than text because it's easier and clearer for non-native people like me, but I'm fine to switch to text if text is better. Your proposal is helpful, should I make a switch?

For E, you had a separate paragraph:

> I think it might be better to omit reference to HO at this point, I'm not sure that
> property is going to pass full Unicode committee approval given that it's effectively
> defining a character property that represents the condition [script == Mongolian or
> Phags-pa].

HO was approved at the last UTC conference in May. It's not approved by full committee, and anything may change until it goes final, or even after that, but I can't find any good reasons not to use it. If we want to avoid using HO, the condition will be a bit more complex, because there are some code points where Script=Common and ScriptExt=Mong Phag. We could add that, but then we have to define behavior if future code points had, say, ScriptExt=Hani Mong Phag. I don't know what the expected behavior for such code points. I don't know if we were to find other scripts to add to this category in future. HO may be gone in future, but not relying on it makes our spec more complicated.

Also, if you agree with making derived properties, we're stable regardless of HO. It only matters how to derive, and the result stays the same. This is one of the benefits to derive. So if you agree with derived properties but not using HO, I'm fine to go either, but I have a mild preference to HO because it simplifies our spec.


Regards,
Koji

Received on Friday, 29 June 2012 08:28:24 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:55 GMT