Re: [css3-multicol] overflow and paging?

Let me clarify this more, and correct a typo is the wording I suggested...

This is rather important. I hope everyone reads this.

> Maybe I can perfect it on this iteration...
>
>
>> Also sprach Shelby Moore:
>>
>>  > Thus I offer an optional suggestion to place that in its own section
>> as
>>  > follows, and I would further be more correct (and clear that column
>> rows
>>  > are atomic and that page direction overflow is in the block
>> direction)
>> by
>>  > including the word 'row' (perhaps 'row' bold or italic to emphasize
>> it),
>>  > this implies that the page is a constraint on the column height too,
>> but
>>  > you might want to state it explicitly:
>>  >
>>  > 8.3 Overflow of page in paged media
>>  >
>>  > The page boundary constrains the column height and column rows that
>> do
>> not
>>  > fit within the page are moved to the next page.
>>
>> I can't parse that. I can see ways of making it parsable, but I'd
>> rather have it from you.
>
>
> I was trying to be less verbose.  Follows the uncompacted version.
>
>
> 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 page.

That was missing a word 'the':

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.


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.

(2) Thus I removed "In paged media, the column height is constrained by
the size of the page." from 8.2 and merged it above into the proposed 8.3
above.

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

(4) Thus I would also suggest the title for section 8, needs to change to
reflect that 'overflow' is orthogonal to pagination:

8. Overflow, page media, and multicol elements

I have more comments at bottom of this email...


>>  > Or if you prefer to be less verbose and make column height constraint
>>  > implied (but I prefer the one above):
>>  >
>>  > 8.3 Overflow of page in paged media
>>  >
>>  > Column rows that do not fit within the page are moved to the next
>> page.
>>
>> I'm not sure we should include 'row'. The only reason why the row
>> comes into existance is because the column boxes don't fit, right? So,
>> rows are created after pagination, not before.
>
>
> But if you don't put row, it is not clear if the column height extends to
> the end of the document, or if the column height is clipped at the page
> boundary. I know we assume it is clipped because that is what we are all
> used to, but that is not what would be said if we didn't include row or
> some reference to column height.  That reference was in the first part of
> 8.2, but I am trying to unconflate overflow and pagination, as you pointed
> out this conflation could be a source of confusion.
>
> The column height is critical, because it dictates the order that the
> content flows into the columns.  If the column height is not clipped, then
> you get this error:
>
> 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
>
>
>
>
>>
>>  > 8.2 Overflow outside multicol elements
>>  >
>>  > Columns honor 'overflow' and always overflow in the inline direction
>> when
>>  > the column height is constrained. The column height may be
>> constrained
>> for
>>  > example by using 'height' or explicit column breaks.
>>
>> This is not quite correct. It's not the columns that honor 'overflow',
>> it's the multi-column element.
>>
>> I'm also trying to minimize the number of changes in the draft. The
>> draft is a Candidate Recommendation, so only necessary clarifications
>> should go in.
>
>
> At least this could (should?) be removed from 8.2, "In paged media, the
> column height is constrained by the size of the page." and moved to 8.3.
>
> Even with that, I find 8.2 to be hard to parse. Here is another
> suggestion, maybe it is just a matter of taste, you decide. Imo the
> following is more comprehensible to the average person.  Note I added
> 'row' too. I think it is really important to get people to realize we are
> not talking about height but column height.  That is very big source of
> confusion, I can see that from the discussion in this thread.  Imagine how
> confused the layman designers will be.
>
>
> 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

(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 11:50:14 UTC