W3C home > Mailing lists > Public > www-style@w3.org > October 2010

Re: [css3-multicol] overflow and paging?

From: Shelby Moore <shelby@coolpage.com>
Date: Tue, 19 Oct 2010 16:26:10 -0400
Message-ID: <f15cd8e3f7b6f2f63c5d641c7ed9e727.squirrel@sm.webmail.pair.com>
To: "Håkon Wium Lie" <howcome@opera.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "Andrew Fedoniouk" <news@terrainformatica.com>, www-style@w3.org
> Also sprach Tab Atkins Jr.:
>  > When time is available, the editor of the Multicol spec (Hakon) will
>  > decide how to edit the spec.
>  >
>  > Don't worry, feedback doesn't get dropped.  It can take time, though.
> Indeed. I'm been trying to follow the discussion, a bit from the
> sideline. It seems the the CR needs one clarification.
> Shelby wrote:
>  > IMO, section 8.2 is not optimally succinct and coherent. Let me
> translate
>  > it. Section 8.2 means that the column height must never exceed the
> block
>  > direction constraint, if it exists. Section 8.2 also means that when
> the
>  > block direction constraint is not due to a page border, then the
> columns
>  > should overflow in the inline direction. The current spec 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 the spec says for continuous media, and
> thus
>  > my specification above is more correct (and IMO more succinct and
>  > coherent).
> I agree that the current wording:
>   In paged media, columns that do not fit within the page are moved to
>   the next page.
>   http://www.w3.org/TR/css3-multicol/#overflow-outside-multicol-elements
> incorrectly implies that overflow situations in paged media are always
> handled by moving content to the next page. And that's not the case.
> Therefore, I suggest this rewording:
>   In paged media, columns that do not fit within the page due to
>   constraints imposed by pagination are moved to the next page.
> Does this address your concerns, Shelby?

I wasn't suggesting any change to that part, because I thought 'page'
implies "pagination on paged media", especially given the "In paged media"

Now that you raise it, I can see some confusion with that part could be
that it is within the section 8.2 which is entitled "Overflow outside
multicol elements". I also see a problem that 'rows' was not specified.

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.

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 also open for rewording the other parts of 8.2 if you have
> concrete proposals.

The first part of 8.2 is what I was originally giving feedback on. I will
suggest a much more succinct wording as follows (which benefits from the
rewording of the proposed section 8.3 above):

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.

> It seems that the other part of this debate -- how to increase
> influence over how overflow situations are handled -- must be left for
> a future draft.

I am happy enough you are aware of it. Does that mean not in CSS3, or
possibly in a next draft of CSS3?  Apologies I am ignorant of the process

Thanks very much for replying on this.

Received on Tuesday, 19 October 2010 20:26:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:39 UTC