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

Re: [css3-multicol] overflow and paging?

From: Håkon Wium Lie <howcome@opera.com>
Date: Tue, 19 Oct 2010 20:58:10 +0200
Message-ID: <19645.59970.419790.923002@gargle.gargle.HOWL>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: shelby@coolpage.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.


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

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. 

On this, Brad wrote:

 > What's really needed for you use case is a way to handle overflow
 > differently, so that it is paged, or otherwise worked more like the
 > constraints of a fixed page size. The obvious place to handle that
 > is with a new value for the 'overflow' property.

I agree. This is consistent with the CR which states:

  Content that extend outside column boxes at the edges of the
  multi-column element is clipped according to the ‘overflow’


In the past, I have proposed:

  body { overflow: paged }


I like the syntax, but the feature hasn't been defined to the level of
detail we need. But this is out of scope for CSS3 multicol -- we're in
CR and want to move forward. We've already sacrificed useful functionality
to go to CR.

Let me know if I have missed any other change proposals that are in
scope for the current CR.


              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Tuesday, 19 October 2010 18:58:54 UTC

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