Re: [css3-multicol] overflow and paging?

Let me clarify why I say the CR is 'broken' and not just 'limited'...

[snip]

>> 8.2 Overflow outside multicol elements
>>
>> Multi-column elements support 'overflow', and always overflow in the
>> inline direction when the column row height is constrained. The means
>> additional column rows can not be created, except by paged media.
>>
>> The column row height may be constrained for example by using 'height'
>> or
>> explicit column breaks.
>
> Typo, "always overflow" should be "always do any overflow"
>
> Points about the above suggested wording:
>
> (1) It is important that we point out that in the current CR, there is no
> possible way to achieve more than one row of columns without paged media.
> This is not at all obvious from the specification, and just by raising
> that point, it cause the reader to really think and stop conflating
> 'height' and column row height, which I could see in the discussions in
> this thread was a major source of misunderstanding:
>
> http://lists.w3.org/Archives/Public/www-style/2010Oct/0271.html
>
> It is also important to make that point, because that is precisely the
> reason that the multicol standard needs to be improved, per my points in
> this thread. For example, it is the fundamental reason why Daniel Glazman
> is noting that the current CR is broken for accessibility[*] (because
> current CR does not allow rows of columns, so that accessibility can't
> page columns vertically with a "Next" button). And it is the reason I can
> not get correct sort order on the display of user profiles in columns in
> my social network, and had to revert to multicol DIV nesting another DIV
> of content in order to force the 'overflow' to be in the block direction
> (but I don't get correct column height and thus I still get only 1 row of
> columns and thus incorrect sort order in the visible portion of the
> multicol DIV).
>
> If you feel you can release a standard which is knowingly broken in that
> way, then I am at least asking that we get the wording correct and clear.
> Sorry that requires significant changes to 8.2.
>
> [*] http://lists.w3.org/Archives/Public/www-style/2010Oct/0285.html


It is 'broken' because when you release this as official standard, then
the only way for designers to get overflow in the block direction (which
is absolutely needed for any vertically scrollable columns), is for them
to do what I did and nest the content in a DIV which is nested in the
multi-column DIV.

But what that does is pollute the web with columns that do not have their
flow order correct, as per the following diagram. It will be much harder
to get these fixed by releasing a better standard later.

multicols { column-width:100px }
scrolling { overflow:auto; height:100%; width:200px }

<div class='multicols scrolling'>
  <!-- these are sorted and order is important -->
  <img src='A' height='50%'/>
  <img src='B' height='50%'/>
  ...
  <img src='H' height='50%'/>
</div>

Does not scroll vertically:

----
|AC|EG
|BD|FH
----
   ^right of this is scrollable horizontal overflow

So we must do:

<div class='multicols scrolling'>
  <div>
     <!-- these are sorted and order is important -->
     <img src='A' height='50%'/>
     <img src='B' height='50%'/>
     ...
     <img src='H' height='50%'/>
   </div>
</div>

But the above, produces the wrong flow order:

----
|AE|
|BF|
---- bottom of multicol scrolling div, below is overflow
 CG
 DH

What we really want is impossible in current CR:

----
|AC|
|BD|
---- bottom of multicol scrolling div, below is overflow
 EG
 FH


>
> (2) There is no reason to mention "continuous media" in this unconflated
> version of 8.2, because 'overflow' applies to both continuous and paged
> media.  And because the even in paged media, the overflow will be in the
> inline direction when the "column row height" is constrained. The
> statement from the current 8.2 is wrong because is says this does not
> occur in paged media, "In continuous media, columns that do not fit within
> the multicol element are added in the inline direction."

Received on Wednesday, 20 October 2010 13:44:38 UTC