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

On Apr 10, 2013, at 8:32 AM, James Holderness <j4_james@hotmail.com> wrote:

>> Note that Opera's implementation uses overflow-x and overflow-y, as they are longhands on overflow, and get the values from it.
>> 
>> http://www.opera.com/docs/specs/presto2.11/paged-overflow/
>> 
>> This is different from what was specified in GCPM, which uses overflow-style.
> 
> I've been experimenting with the Opera implementation a little, and I'm not sure I fully understand how it is supposed to work.
> 
> If I create a block with a fixed width and height, and enough lines of text that would overflow the height of that block, setting overflow:paged-x lets me view the vertical overflow by paging horizontally, and overflow:paged-y lets me view the vertical overflow by paging vertically. That's all great.
> 
> However, if instead of overflowing vertically, I create a long line of text with no spaces that would typically overflow horizontally, none of the paged overflow settings seem to have any effect. I would expect something like overflow:paged-x to work similarly to overflow-x:scroll (only paged) but it doesn't.

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.

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

> In an ideal world I would like to have content that overflowed both vertically and horizontally and then set overflow-x:paged-x and overflow-y:paged-y, resulting in a virtual grid where you could page both vertically and horizontally to pan across all the available content. Is that wishful thinking?

Wanting a virtual grid is reasonable. But what would you do if you had this:

body { overflow-x: paged-x; overflow-y: paged-x; }

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:

overflow-x: [ visible | auto | scroll | paged ]
overflow-y: [ visible | auto | scroll | paged ]

And we could even say that 'overflow:paged' is shorthand for 'overflow-y: paged; overflow-x: auto;'.

Received on Wednesday, 10 April 2013 16:52:16 UTC