Re: [css3-writing-modes] vertical writing mode and visual formatting

Koji Ishii wrote:
> Hi Alan,
> 
>> By declaring a writing-mode, what we establish is a 'block progression
>> context'. In saying this Koji, the concept is at this moment undefined
>> or as I would say, unforeseen. I do propose that we do have such a
>> thing as a 'block progression context'.
>>
>> The default writing-mode is lr-tb (ttb block progression and ltr
>> inline progression). This should be mentioned along with the above
>> mentioned 'block progression context' in CSS2.1.
> 
> If I understand correctly, I think you're talking about page progression:
> http://dev.w3.org/csswg/css3-page/#progression


No, page progression is talking about progression of paged media [1].

   | Paged media (e.g., paper, transparencies, photo album pages,
   | pages displayed on computer screens as printed output
   | simulations) differ from continuous media in that the content
   | of the document is split into one or more discrete static
   | display surfaces.


I am talking a block progression. Taking some simple markup with no 
CSS we have this for both horizontal ltr and rtl inline progression.


|----------|
| xxxxxxxx |
|          |
| xxxxxxxx |
|----------|


There is one major way for overflowing blocks to overflow the viewport.


|-----------|
| xxxxxxxxx |
|           |
| xxxxxxxxx |
|-----------|
   xxxxxxxxx

   xxxxxxxxx


Very wide inlines (or blocks that are wider then the initial
containing block) overflow to the right in ltr and to the left in rtl


   |---(ltr)---|
xxxxxxxxxxxxx |
   |-----------|


   |---(rtl)---|
   | xxxxxxxxxxxxx
   |-----------|


Vertical block progression is different.


   |-----------|
   | x   x   x |
   | x   x   x |
   | x   x   x |
   |-----------|


There are two ways for overflowing blocks to overflow the viewport.


   |--(tb-rl)--|
x | x   x   x |
x | x   x   x |
x | x   x   x |
   |-----------|


   |--(tb-lr)--|
   | x   x   x | x
   | x   x   x | x
   | x   x   x | x
   |-----------|


And for overflowing inline boxes (not images) like long URIs or blocks.


   |--(tb-rl)--|
   | x   x   x |
   | x   x   x |
   | x   x   x |
   |-----x-----|
         x

   |--(tb-lr)--|
   | x   x   x |
   | x   x   x |
   | x   x   x |
   |-----x-----|
         x



> As also John pointed out, you're right that what UI should do with right-to-left page progression is not covered in the spec.


I talking about it being specified is CSS2.1 focusing on it's top left 
bias of lrt inline progression and ttb block progression.


> I'm not sure if it should be in the scope of this spec, or of any other specs.


I not sure if you are following me. In the various threads regarding 
vertical text there has been mention several times extra properties of 
float which are start and end. None of which has any consequence in 
vertical text since there is only two logical directions for floating 
in a 'block progression context'.


> I'll talk to some folks to see what we should do.


Your most welcome to do that. :-)

I do suggest that they take a look at these test in IE8.

<http://css-class.com/test/css/bidi/kanji-test1-extra.htm>

<http://css-class.com/test/css/bidi/mongolian-test1-extra.htm>


>> Currently IE8 and IE9 beta treats the above tb-rl box as a 'block
>> formatting context' [2]. This means that a float that is within tb-rl
>> box will not overlap the tb-rl box. This I believe is a buggy way of
>> handling vertical text, even in small fragments. The same happens in
>> IE8 and IE9 beta just by setting inline progression to rtl.
> 
> Overwrapping floats seems a product bug to me, and it's probably better for a product bug to talk to the vendor rather than here.


Arron, hello.

Koji, would you like to see authors actually used dual layouts for 
Chinese and Japaneses in IE9 without letting a whole new generation 
of bad coding practices to gain hold. A 'block formatting context' 
triggers hasLayout in IE8 and IE9 beta. The is one reason why I'm 
suggesting block progression context.



> I have to admit that I'm still at learning of CSS, and thus I can't be sure if the combination of current CSS 2.1 box model and current writing-mode spec covers the case you're talking about properly. So, from what you're saying, it's not clear to me that you're talking about a CSS spec bug or a product bug, but for now, it looks like a product bug to me. Am I correct on this?
> 
> 
> Regards,
> Koji


Since you're still learning CSS, I would suggest that you listen and 
attempt to understand what I'm am saying. If you have a problem, ask 
questions.


It is not a product bug per say, it's implementing a spec without 
fully comprehending how it is not following CSS2.1.


I will follow up with more, need sleep.


1. <http://dev.w3.org/csswg/css3-page/#intro>




-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo

Received on Wednesday, 27 October 2010 15:50:25 UTC