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.

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.

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. 

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

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

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

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

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Wednesday, 20 October 2010 22:17:26 UTC