- From: Morten Stenshorne <mstensho@opera.com>
- Date: Thu, 11 Apr 2013 10:57:10 +0200
- To: James Holderness <j4_james@hotmail.com>
- Cc: "Brad Kemper" <brad.kemper@gmail.com>, HÃ¥kon Wium Lie <howcome@opera.com>, "Florian Rivoal" <florian@rivoal.net>, "www-style list" <www-style@w3.org>
James Holderness <j4_james@hotmail.com> writes: >> > Is this something that's just not supported? Does paged overflow >> > only apply to content that overflows vertically or is there something >> > else I'm doing wrong? >> >> It only applies to vertical overflow, it seems. But what you are >> doing, expecting it to apply to horizontal overflow too, seems very >> reasonable. > > There's one exception I've found so far. If the block is a > multi-column element, which by default would overflow horizontally, > setting overflow:paged-x or overflow:paged-y does seem to work. I'm > not sure why that is though. That's an interpretation of http://www.w3.org/TR/css3-multicol/#pagination-and-overflow-outside-multicol Additional column boxes are moved to the next page(s). >> Wanting a virtual grid is reasonable. But what would you do if you had >> this: >> >> body { overflow-x: paged-x; overflow-y: paged-x; } > > I have thought about that, but I didn't see a simple solution. > > You'd obviously start by breaking the content up into pages as you > would for a regular paged grid, but you then have to layout those > pages in only one dimension. That can either be by taking a row at a > time, or a column at a time, but the preferred option will depend on > the type of content, so it seems like there ought to be a choice. > > I'm not sure that's worth the complication though. Is that really a > use case that you want to support? I'm not sure about this grid thing. How would you go about numbering the pages, for instance? Is there even an intuitive way? I realize that not being able to display overflowing content in the inline direction is a limitation in Opera's implementation, though (WebKit's too, BTW), but I suspect that could be handled by regular scrollable overflow. If you have "overflow:paged-y" and long unbreakable inline content, I suppose there should be a horizontal scrollbar to scroll inside of the current page. If you have "overflow:paged-x" and long unbreakable inline content, on the other hand, the overflowing content could probably just bleed over to the next page. Then there's the multicol spec again, which says that overflowing content is clipped at the middle of the column gap [1]. And paged containers are very similar to multicol containers (also on the implementation side, both in Presto and in WebKit). If it's okay to lose overflow in multicol containers, why not in paged containers? Or perhaps it's wrong to unconditionally clip both for multicol and paged, and that there should be a multicol property to control it for multicol containers, while we should just do what the overflow properties say in paged containers (e.g. overflow-y:paged-x; overflow-x:auto /* and not just behave as if it's always set to 'hidden' */; } [1] http://www.w3.org/TR/css3-multicol/#overflow -- ---- Morten Stenshorne, developer, Opera Software ASA ---- ---- Office: +47 23692400 ------ Mobile: +47 93440112 ---- ------------------ http://www.opera.com/ -----------------
Received on Thursday, 11 April 2013 08:57:53 UTC