W3C home > Mailing lists > Public > www-style@w3.org > October 2010

RE: [css3-writing-modes] a third option for implementing logical properties

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Mon, 25 Oct 2010 06:25:58 -0400
To: Håkon Wium Lie <howcome@opera.com>, David Hyatt <hyatt@apple.com>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0AA3634150@MAILR001.mail.lan>
>  > Logical properties were trivial to implement in WebKit
> 
>  > I still think they're the best solution that has been proposed for  >
> producing a layout that can work in both the horizontal and  > vertical
> directions.
> 
> Implementation cost is one metric, but no the only one. For one, there's
> also a memory cost. I presume you have implemented this so that the logical
> propertie cascade and inherit separately? on a per-element basis? And cannot
> be resolved until you know the computed value for 'writing-mode'? If so,
> the memory use will be significant: ~35 property values for every element.

I understand your concern. I don't stick to one particular syntax, but I insist on the basic idea of the logical directions.

Does the idea from John help to reduce memory use? I think his proposal can be one of the best solutions for the logical directions from author's point of view.


>  > I still think they're the best solution that has been proposed for  >
> producing a layout that can work in both the horizontal and  > vertical
> directions.
> 
> There's also the inside/outside duality. If we want to address that issue
> with a similar property-doubling approach, we need another 35 or so
> properties.

John's idea is extensible to inside/outside as well. We could add another keyword like "page-logical" or "mirror-if-even-page" to make it happen.


> And then there's the values. For example, 'float' accept 'right', 'left',
> 'top', 'bottom' (in GCPM). Should we duplicate these? There's a long list
> of issues like these that will come up.

Yes, that's an issue we need to address before writing-mode goes to CR. I don't have answers right now yet but I'm aware of that I need to work together with GCPM.

And you're also right that it's just an example of possible issues in future. I agree with you that there's a long list. As I said before, vertical flow isn't just as easy as small features like emphasis marks, but it's still worth to spend that much efforts, and I'm willing to do that. That effort should help any CSS-based software in East Asia in the long run, so I guess it's good for us all.


> Rather, I think it's better to continue to use the existing property names
> -- top, right, bottom, left are universal concepts with no bias.
> Then we use media queries or some other syntactic construct to shield legacy
> implementations. No new properties, no new syntax, and better
> results: values aren't simply mirrored, but can also be set specifically
> for the writing direction.

Your points taken, but again, I hope John's proposal resolves most of your concerns. Does it?

IEC 62448 took the approach to alias "top" and "left" in vertical text flow as I wrote. It may look weird, but the benefits of logical directions won over the weirdness for them. The benefits of logical directions are so big for East Asians, and the fact that 100K books published so far in the format supports it. I hope us be much smarter than that.


Regards,
Koji
Received on Monday, 25 October 2010 10:23:47 GMT

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