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

> That is the sort of thing I was trying to describe to Håkon. The need
> to deal with overflow-x does not go away with paged overflow, but the
> current spec seems to ignore that need.

I thought we might have been talking about the same thing. But it wasn't 
quite clear to me what the GCPM spec was saying (or the Opera spec for that 
matter). At least the Opera implementation let me experiment to see what it 
was actually doing which is helpful in these discussions.

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

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

> My view is that the UA or OS should have a standard for paged overflow
> UI, just as it does for scrolling. So that might be a grid that you
> pan around on that always snaps to a page, or it might be with the
> rows of that grid arranged in the z-axis so that swiping in one way
> slides/turns/curls the current page of the top of the stack, and
> swiping in a different way reveals the page of the horizontal axis.
>
> If this behavior is standard for the UA or OS, then the user benefits.
> If it really needs to be customized, it should be via an @rule for the
> document, perhaps like so:
>
> @scroll-style { block-progression-style: [ curl | slide | push ];
> inline-progression-style: [ curl | slide | push ]; }
>
> Either way, we don't need paged-x and paged-y, just the overflow-x and
> overflow-y that all authors are used to. So the choices would be:

I like the simplicity of this solution, but I have one use case that I don't 
think is covered.

When we do columned magazine layouts, we create a multi-column element for 
the article with a constrained height so that it overflows horizontally. 
Typically the design calls for horizontal paging to read the article (what 
would be overflow:paged-x on Opera), but sometimes publishers prefer the 
article paged vertically (essentially overflow:paged-y), so they can reserve 
horizontal paging to jump straight to the next article.

To support this case you have to have a way to take the multi-column 
element's horizontal overflow, and page it vertically. I don't see how you 
could do that with your proposal.

Then again, this may be something that you don't feel is worth supporting. 
But it has been a real use case for us.

Regards
James

Received on Wednesday, 10 April 2013 18:19:12 UTC