Re: [css3-multicol] overflow and paging?

> Shelby Moore wrote:
>
>  > Let me clarify this more, and correct a typo is the wording I
> suggested...
>
>  > 8.3 Paged media
>  >
>  > Columns that do not fit within the page are moved to the next page, and
>  > the column row height, for those columns that were not moved, is
> clipped
>  > to the page.
>
> The first part of your proposal is already in the CR:
>
>    In paged media, columns that do not fit within the page are moved
>    to the next page.

I said pagination is not overflow. Thus, the two things need to be
unconflated into their own sections. And I gave an example of how the
conflation gives wrong specification.

> The second part is, I believe covered by this, which is also in the
> CR:
>
>     In paged media, the column height is constrained by the size of
>     the page.
>
> So I don't understand what your text says that the current text doens't.

Ditto.

> Further, I'm not convinced that "clipped" is the best word to use --
> columns are generated when necessary, much like lines. And it doesn't
> seem right to say that lines are "clipped" either.

You need to define that the column row height is. Otherwise it is
ambiguous, meaning that content can flow all the way to the end of the
book in the first column of column boxes, then all the way to the top of
the book for the next column of column boxes.

The spec defines the column row height orthogonally to the column boxes
that get moved to the next page:

http://www.w3.org/TR/css3-multicol/#the-multi-column-model

>  > Points about the above suggested wording:
>  >
>  > (1) I unconflated section 8.2 and paging, because 'overlow' is an
>  > orthogonal setting to paging. Conflating the concepts can lead to
>  > misunderstanding and incorrect specification, as I had explained in
> prior
>  > emails. For example, the current 8.2 could be misinterpreted because
> paged
>  > media may also contain instances of block direction constraints which
> are
>  > not due to a page border and such cases should be treated the same as
> 8.2
>  > currently ERRONEOUSLY says IS ONLY FOR continuous media.
>
> The CR states:
>
>   In continuous media, columns that do not fit within the multicol
>   element are added in the inline direction.
>
> We could address your point by adding:
>
>   In continuous media columns that do not fit within the multicol
>   element are added in the inline direction. This is also the case in
>   paged media when the column height is constrained by declarations
>   (as opposed to natural page breaks).


Why insist on conflating pagination and overflow.

Instead we can make less verbose, more orthogonal, and less difficult to
separate concerns.

>  > (3) I added the part about "column row height" because the current 8.2
> is
>  > ambiguous and does not specify what the column row height is when
> columns
>  > are moved to the next page.
>
> I believe this is described by this text in section 2: "If the
> multi-column element is paginated, then the height of each row is
> constrained by the page, and the content continues in a new row of
> column boxes on the next page; a column box never splits across
> pages."

Great. Then you can remove 8.3, and go with the much more succinct version
of 8.2 that I provided. We can thus remove all that page media conflation
in 8.2 as I did.

>  > In the current 8.2, the two following cases
>  > are both possible, but in fact we want only the second case to be
> allowed
>  > as follows:
>  >
>  > > A E
>  > > B F
>  > > ----- page boundary
>  > > C G
>  > > D H
>  > >
>  > > Whereas the correct is to clip the column height to the page, so that
> you
>  > > get:
>  > >
>  > > A C
>  > > B D
>  > > ----- page boundary
>  > > E G
>  > > F H
>
> I believe the the text in section 2 addresses your case. That is, the
> text states that "the content continues in a new row .. on the next
> page".

Yes Section 2 does, we can thus eliminate my proposed 8.3 and we can use
the unconflated version of 8.2 that I provided which is more succinct,
more orthogonal, and easier to separate concerns.

8.2 Overflow outside multicol elements

Multi-column elements support 'overflow', and always do any 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.


> I'm kind of getting lost in the rest of the comments you made. I hope
> I have addressed your concerns above.

The rest of it is the most important part of the post, so I will repeat it
again below, because it has not been addressed yet.


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

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


================================
================================
================================

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 Thursday, 21 October 2010 05:25:55 UTC