- From: Shelby Moore <shelby@coolpage.com>
- Date: Tue, 19 Oct 2010 18:55:46 -0400
- To: "Håkon Wium Lie" <howcome@opera.com>
- Cc: www-style@w3.org
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. > > > 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.
Received on Tuesday, 19 October 2010 22:56:14 UTC