Re: [css3-multicol] overflow and paging?

> On 10/11/2010 10:55 AM, Shelby Moore wrote:
>>
>> The problem is that that I expect the columns in pane(1) to be paginated
>> to the height of pane(1), so there will be page breaks __WITHIN__
>> pane(1).
>> There are no page breaks for the viewport, because the panes(1) and (2)
>> never are taller than the viewport.  I have no way to make the inline
>> content less tall, because the border between pane(1) and pane(2), is
>> draggable by the user.
>>
>> In other words, I expect the following in pane(1) where my inline
>> content
>> is in alphabetical order:
>>
>
> Rendering A
>> -------------
>> |           |
>> -------------
>> |A D|       |
>> |B E|   2   |
>> |C F|       |
>> -------------
>>  G J
>>  H K
>>  I L
>>
>>  M P
>>  N Q
>>  O R
>>
>> But instead now I erroneously see:
>
> Rendering B
>> -------------
>> |           |
>> -------------
>> |A J|       |
>> |B K|   2   |
>> |C L|       |
>> -------------
>>  D M
>>  E N
>>  F O
>>  G P
>>  H Q
>>  I R

I refer you to the better and later examples of that:

http://lists.w3.org/Archives/Public/www-style/2010Oct/0421.html

And the reasons we must make the _default_ case Rendering A always.


(I) http://lists.w3.org/Archives/Public/www-style/2010Oct/0421.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."


(II) http://lists.w3.org/Archives/Public/www-style/2010Oct/0417.html

"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...

...It is also important to make that point, because ... 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)."


(III) http://lists.w3.org/Archives/Public/www-style/2010Oct/0454.html

"What is the justification for allow cases that can forcing scrolling from
bottom to top of document in order to read left-to-right?

Shouldn't the default be to not to do that, then you can work on adding
your other cases in the future?

I can't understand punting on this one.  You are going to have a lot of
angry people out there asking who made this decision?"


(IV) http://lists.w3.org/Archives/Public/www-style/2010Oct/0473.html

"...at least improving the scrolling so that we
are not scrolling from bottom to top of the entire document just to read
left-to-right."


> If you constrain the height of the multicol element, you should instead
> see
> Rendering C
> ---------------
> |             |
> ---------------
> |A D|G J M P  |
> |B E|H K N Q  |
> |C F|I L O R  |
> ---------------
> where the columns overflowing to the right can be clipped or scrolled
> depending on 'overflow'.
>
> You get Rendering B if you do not constrain the height of the multicol
> element.


Agreed. That isn't my point.


> You can get Rendering A only if we add a new property, 'column-length',
> as described in the minutes from the Oct 2008 F2F;
>    http://lists.w3.org/Archives/Public/www-style/2008Nov/0023.html

We don't need column-length.  We simply need to use the constrained height
of the overflowed multi-col element as the column row height. And this
should be the default, instead of the way it is now.  That is why we must
fix this before we release this CR.  It is a default setting that is
involved here.

> Rendering A is somewhat awkward in a scrolled presentation; *therefore*
> there was a suggestion for "overflow-style: paged".

No rendering A is the least awkward.  Rendering B forcing the user to
scroll to the end of the document and back to the top just to read
left-to-right. And it kills accessibility.  You currently have rendering B
as the defacto default, because if the designer wants vertically overflow
scrolling, they will nest the element inside the multi-col element.

Don't tell me that the inline overflow is the default, because it is not. 
The designer will nest to get what they want.

That is the crucial thing you are missing in your computation of impact of
not fixing this before release.

Please read this:

http://lists.w3.org/Archives/Public/www-style/2010Oct/0473.html

> Both 'column-length' and 'overflow-style: paged' were deferred to
> future specs at the Oct 2008 F2F.

Please read this:

http://lists.w3.org/Archives/Public/www-style/2010Oct/0473.html

The default can be fixed now.  It is orthogonal to more generalized
overflow paging setting.  Column-length is unnecessary for this default.

> Probably CSS4 Multi-col will have 'column-length', and some as-yet-
> undetermined spec will have 'overflow-style: paged'. ('column-length'
> would be very easy to specify; 'overflow-style: paged', however,
> seems not as straightforward.)

But that has nothing to do with this current default issue.

Received on Thursday, 21 October 2010 05:45:50 UTC