Re: [css-overflow-3][css3-marquee][css3-gcpm] x/y directions (maybe [css3-break] too)

On Apr 11, 2013, at 1:57 AM, Morten Stenshorne <mstensho@opera.com> wrote:

> 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?

When Excel prints a large spread sheet, it deals with this via tiling (as did Adobe Illustrator that I mentioned before). Horizontal overflow produces more pages, just as vertical overflow does. I believe the numbering is left-to-right, then top-to-bottom.

Of course, what you end up with in your printer is just a big single stack of paper, stacked in the z-axis in that page numbered order, and I think that is fine as a model for how the UA could animate the page to page transitions. 

The more I think about it, the more convinced I am that it is the job of 'overflow-x:paged' and 'overflow-y:paged' to only create the pages, not to decide for the UA what special effect is used for switching between pages. I should be able to author those properties to those values and be done with it. The UA could treat the transitions between x-overflowed pages differently from y-overflowed pages, but it wouldn't need to. Personally, I think if there was a page curl animation between pages, then it should be the same for x as y overflowed: it's just a big stack of ordered pages. If the animation is more of a scrolling page-to-page effect, as Håkon imagined, then a two axis animation of pages pushing each other out of the way might be more appropriate for the two types of overflow. Or all pages could push up from the bottom.

The point is that deciding the mechanism and animation for moving between pages is really a separate problem from deciding how to turn overflow into pages. There should at least be a default way of animating and actuating that change that is independent of just setting 'overflow-x:paged' and 'overflow-y:paged'. In Flipbook for iPad, the pages flip to the left, and in Flipbook for iPhone, they flip up. In iBooks, the pages curl to the left in one mode, and push up from the bottom in another mode. In Kobo, the user can set the "page transition style" to either a page curl or a page fade. If we wanted to give authors this capability, we could have either an @rule as I previously described, or as a separate inheritable property ('page-transition: [none | fade | curl | push | slide-reveal | <custom-animation>] [<speed>]*').


> 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.

That would be 'overflow-y: paged; overflow-x: auto'. That might be a reasonable longhand for 'overflow: paged'. Or perhaps 'overflow-y: paged; overflow-x: hidden' would be better (I don't think so, but some here might). 

> 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.

In other words, a page is a page, whether it is due to horizontal overflow or vertical overflow. Right?

> 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' */; }

I'm not sure I followed your point about multi-col, but I agree that we should not just behave as if overflow-x always set to 'hidden' when overflow-y is set to 'paged'.

> 
> [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 14:56:10 UTC