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

>> I'm not sure we need per-element switches, though. I think the use
>> case is more for different document modes. For example, a button on a
>> Japanese tablet that toggles between vertical and horizontal layout.
> 
> That's one thing I'm wondering as well.  Is there really any desire to be abstract at the element level (other than on the part of the UA, who can always just use internal logical properties that aren't exposed to authors)?  If the switching really is done at a document level, then a media query makes a lot of sense.

Yes, switch at the element level is critical. This is an example of typical simple page composition of Japanese literature:
http://www.w3.org/TR/2009/NOTE-jlreq-20090604/ja/images/img1_3.png

At the top of the page you see "第5章 原稿整理". This is the title of the section 5 and laid out horizontally. Also, notice at the bottom of the page the page number is in horizontal.

Magazines also mix vertical and horizontal writing and it can be fairly complex.
http://www.oshmans.co.jp/blog/img/2009/03/dscn4029.jpg
http://fujisan.typepad.jp/photos/uncategorized/2009/07/01/topposter_4.jpg
http://blog-imgs-30-origin.fc2.com/k/u/n/kunikitakaharuweb/20100122190822401.jpg

- kida

On 2010/10/24, at 16:01, David Hyatt wrote:

> On Oct 24, 2010, at 5:32 PM, Håkon Wium Lie wrote:
> 
>> Also sprach David Hyatt:
>> 
>>> What about allowing named sub-blocks within a declaration block?
>>> Then everything could cascade properly. Maybe via a new @-rule.
>>> 
>>> @writing-mode p {
>>>  horizontal {
>>>   margin: 1em 0;
>>>  }
>>>  vertical {
>>>   margin: 0 1em;
>>>  }
>>> }
>> 
>> Hmm. So, you're branching based on the computed value of
>> 'writing-mode'? In principle, you could use the same syntax for other
>> properties, e.g.:
>> 
>> @font-style p {
>>   italic {
>>     color: red;
>>   }
>>   normal {
>>     color: blue;
>>   }
>> }
>> 
>> (Not that I would encourage it.)
>> 
> 
> Yeah, basically.  Engines already have to collect the rules and then do a first pass to resolve the properties that the other ones depend on (font, direction, writing-mode) and then do a second pass to compute the values for the other properties.  This means the solution above should be easily implementable in any engine.
> 
>> I'm not sure we need per-element switches, though. I think the use
>> case is more for different document modes. For example, a button on a
>> Japanese tablet that toggles between vertical and horizontal layout.
> 
> That's one thing I'm wondering as well.  Is there really any desire to be abstract at the element level (other than on the part of the UA, who can always just use internal logical properties that aren't exposed to authors)?  If the switching really is done at a document level, then a media query makes a lot of sense.
> 
> It's really a question of whether the logical properties will make authoring significantly easier for those who wish to use them.  I don't know enough about Japanese text layout to say for sure.  I suppose it's a question of how big the stylesheets are for these documents and how many rules you would have to duplicate in order to support both modes.
> 
> dave
> (hyatt@apple.com)
> 
>