W3C home > Mailing lists > Public > www-style@w3.org > July 2011

RE: [css3-writing-modes] text-orientation: upright (was RE: Minutes and Resolutions 2011-07-13

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Fri, 15 Jul 2011 01:11:56 -0400
To: Stephen Zilles <szilles@adobe.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0AC4D1B300@MAILR001.mail.lan>
Thank you Steve for the explanation. I'm relaxed to hear that our goal are the same. I apologize in advance that I was a little off for personal matters these a few weeks and may have missed some discussions. I'm trying to catch up.

> [SZ] The problem is that unlike the specifications for explicit values, the default or "initial"
> value for a property cannot change if backward compatibility is to be preserved; that is
> why it is important to get it right from the beginning. There is no CSS4 new default value.
> It is certainly possible to introduce new explicit values that fix problems with
> 'vertical-rotate', the initial value for 'text-orientation' in CSS4, but if the default value has
> a problem it will stay there forever. It is also possible to introduce a new property with a
> new default/initial value, but that does not seem like a good choice either. That is why I,
> at least, am concerned about having a clear and useful definition of 'vertical-rotate'

I completely agree with you. But I wonder, we're not reviewing what fantasai wrote line by line at all. There are only two bullets in the spec[1], but I can't figure out if we have agreed with
]]
* If the font and font system support mixed-orientation typesetting (e.g. the OpenType font used has the vrt2), the UA should rely on that feature to set 'vertical-right' text. Similarly if the font and font system support upright typesetting (e.g. the OpenType font used has the vert feature) then the UA should rely on that feature to set 'upright' text.
[[

And another bullet is:
]]
* If the UA needs to synthesize such features, then the settings in Appendix C are recommended.
[[
Appendix C is not easy, probably takes hours to review and understand. I feel sorry about that, but it can't be helped because the feature isn't easy.

What I see is, instead of discussing on her proposal, proposing different approaches without touching her original proposal. If we want to discuss completely different approaches, I'd like to know what are the problems or use cases current ED cannot solve.

> On the question of "requirements" for 'text-orientation' default. The original one was to do
> as much of the "right thing" as possible without requiring explicit markup. The original
> model was what Microsoft Word did without markup.

Right, and I haven't heard anything what problems the current ED has against the requirements. I tried to understand all counter proposals as much as possible, including surrounding characters, script tag, bidi-resolutions, but it looks to me that these proposals are gradually leaving apart from the original requirements. That is why I want us back to the original requirements and use cases we want to solve. I believe that is the point dsinger and sylvaing pointed out.

> I think we need to answer the questions that were raised in the Wednesday discussion
> before we can decide on what the default/initial value is to be.

Can you please be a little more specific which questions are you referring to in the minutes[2]?
* For 2011/NASA, current spec solves this by using full-width code points.
* For search between ASCII/full-width, fantasai responded during the discussion.
* For bidi-resolution, I'd like to know what problems current ED has and what we're trying to solve by that.
* For lang tag, the same. What are the problems the current ED cannot solve without that, and what additional values it can give us?
* "we need a default rule" -- yes, we do have a proposal at the bottom of text-orientation[1] and Appendix C[3].
* "what is the mechanism for a person to control things if the rules do not do what we want" -- apply 'text-orientation: upright' to that region. That's the escape hatch Eric requested. For more automatic escape hatch that doesn't require markup changes, I suggest we punt it to level 4.
* "<dsinger> I'm still unclear..." -- I think this is a question for you and John.
* "shapes script should never been shown upright" wasn't answered, but shapes scripts are defined being sideways in 'vertical-right'. Is this a discussion for 'upright'?

If I miss any important questions, would you please point out?

Note for the lang tag, you must know this but since you mentioned Microsoft Word, Word does emit tags like this:
  <body lang=JA>
    <p>[Japanese]<span lang=EN-US>[alpha/numeric]</span>[Japanese]</p>
There are two points I'd like to mention: first, it's not practical to wrap every alpha-numeric in span and apply lang=EN-US for authors. Second, Word uses scripts for font selection but not for text orientation. So, while I agree that tagging scripts are very valuable for formatting purposes, I can't figure out what problems in text orientation you want to solve by using lang tag.

[1] http://dev.w3.org/csswg/css3-writing-modes/#text-orientation
[2] http://lists.w3.org/Archives/Public/www-style/2011Jul/0205.html
[3] http://dev.w3.org/csswg/css3-writing-modes/#vertical-typesetting-details

Regards,
Koji
Received on Friday, 15 July 2011 05:12:04 GMT

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