- From: Håkon Wium Lie <howcome@opera.com>
- Date: Tue, 19 Oct 2010 20:58:10 +0200
- 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. 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'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’ property. http://www.w3.org/TR/css3-multicol/#overflow-outside-multicol-elements In the past, I have proposed: body { overflow: paged } http://lists.w3.org/Archives/Public/www-style/2009Jan/0030.html 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. Cheers, -h&kon Håkon Wium Lie CTO °þe®ª howcome@opera.com http://people.opera.com/howcome
Received on Tuesday, 19 October 2010 18:58:54 UTC