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

Koji Ishii wrote:
> Hi Alan,
> 
>> Test 1 has vertical writing-mode on body.
>>
>> <http://css-class.com/test/css/bidi/kanji-test1.htm>
>>
>> IE8 and IE9 beta render the same. Is this what authors really want? A very
>> long page would overflow endlessly towards the left.
> 
> I think this is an expected behavior. Lines flow right-to-left, and pages flow right-to-left. I can't imagine what else we could design this.


Hello Koji,

This sounds right.


>> Test 2 has vertical writing-mode on div.
>>
>> <http://css-class.com/test/css/bidi/kanji-test2.htm>
>>
>> IE8 overflows to the right and below. Long pages must be scrolled
>> towards the right to get to the beginning of the document. Adjusting
>> the bottom and right or the viewport causes paragraphs lengths to
>> increase or decrease. Sometimes the bottom scrollbar disappear with
>> content overflowing into hidden on both left and right sides. IE9 beta
>> handles this strange. Adjusting the sides (best seen of right edge) of
>> the viewport causes the paragraph to increase or decrease but this
>> causes lot of empty space below.
> 
> As far as I understand, how to determine logical-width (=height) of vertical div within horizontal text flow is still an issue, and I believe fantasai is going to work on that in the box model of the spec in near future. Until the spec is finalized and is implemented, specifying height might be the best practice.


Put aside the bugs with the paragraph's lengths and look at the 
direction of overflow.


The first test has this.

   overflow        viewport
               |-------------|
x  x  x  x  x |x  x  x  x  x|
x  x  x  x  x |x  x  x  x  x|
x  x  x  x  x |x  x  x  x  x|
x  x  x  x  x |x  x  x  x  x|
               |-------------|


The second test has this.

                   viewport       overflow
               |-------------|
               |x  x  x  x  x| x  x  x  x  x
               |x  x  x  x  x| x  x  x  x  x
               |x  x  x  x  x| x  x  x  x  x
               |x  x  x  x  x| x  x  x  x  x
               |-------------|


This is since the first test has the writing-mode declared on the body 
element which seems to propagate to the viewport where the second test 
has the writing-mode declared on a div within the body element. While 
looking into Chinese and Japanese vertical text and mid to late 20th 
century developments, I stumbled onto this page [1]. Note how the 
author got over the direction of overflow by <body 
style="direction:rtl">. The fall back would of course be Chinese or 
Japanese horizontal text going right to left.

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.


>> Test 3 has vertical writing-mode on div with horizontal text first.
>>
>> http://css-class.com/test/css/bidi/kanji-test3.htm
>>
>> IE8 overflows to the right and below. Long pages must be scrolled
>> towards the right to get to the beginning of the document. Vertical
>> text section is moved towards so from the very first paragraph, one
>> must scroll vertically downwards. The amount of the overflow below
>> seems to be the same height as the horizontal text blocks. The
>> paragraph don't seem to increase or decrease in length. IE9 doesn't
>> supply a scrollbar at the bottom towards the scroll right.
>>
>> I do believe the best solution is to overflow downwards like this with
>> vertical blocks.
>>
>> 5  4  3  2  1
>> x  x  x  x  x
>> x  x  x  x  x
>> x  x  x  x  x
>> x  x  x  x  x
>> x  x  x  x  x
>>
>> 10 9  8  7  6
>> x  x  x  x  x
>> x  x  x  x  x
>> x  x  x  x  x
>> x  x  x  x  x
>> x  x  x  x  x
> 
> No, it's multi-column vertical document. I understand you feel it be natural, I actually agree it's nice, but if you rotate it 90 degree counter-clockwise, you'll find that it's multi-column layout. Things that doesn't happen in horizontal text flow doesn't happen in vertical text flow either. To make it happen, you need to wait for multi-column implemented.


See below.


>> Problem 2 is with floats (overflow and overlapping problems) and
>> problem 3 is with block formatting context or lack of block
>> progression context. This I will mention later. I need sleep.
> 
> I'm sorry, I don't understand this part very well. Can you please explain a little more?
> 
> 
> Regards,
> Koji


If you are mixing horizontal with vertical you can not have overflow 
in both directions so I do recommend that authors using both 
horizontal with vertical approach such layout as in test 2. What we 
have is this.


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


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.

<http://www.brunildo.org/test/IE8-direction-bfc.html>


I need to create some test regarding floats showing overlapping badly 
and float disappearing into hidden overflow. This will give you time 
to reflect on what I have written.


1. <http://www.louis-chor.ca/ovltext.htm>
2. <http://www.w3.org/TR/CSS21/visuren.html#block-formatting>


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

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

Received on Tuesday, 26 October 2010 16:12:25 UTC