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

I see that 'overflow-x' is defined as the horizontal dimension, and that 'overflow-y' is defined as the vertical dimension. While this is pretty standard usage of 'x' and 'y' in geometry, I'm wondering if it is not way too late to change this for CSS to be writing mode sensitive.

For instance, if I have 'overflow-y:scroll' on a document with a horizontal inline direction and a vertical ttb block progression direction (like English) on a touch screen (for instance), I would expect a swipe up to advance to the next page. It is a reasonable choice, because as you are reading down towards the bottom of the page, you can read down or move the document up. But if the block progression direction is horizontal rtl, then I'd want horizontal scroll bars, where I could start out on the right, and swipe from the left to reveal more.

The issue is not limited to touch screen, but that's what made me think of it. If the existing behavior is too established, then maybe we could have a new property to switch it, such as 'scroll-coordinates: logical | physical'. 

Maybe this has been discussed before, but I didn't see anything about it in the draft.

Also, if we want to get rid of 'overflow-style' as used by marquee (and I think I do), then having logical x/y coordinates would be enough to handle its needs. That way, you could say 'overflow-x: marquee; scroll-coordinates: logical', and it would animate in the inline direction. 'overflow-x: marquee' would override 'overflow-y: marquee' so that ''overflow: marquee' would automatically be animated in the inline direction only. 

If we need to chose between 'overflow-x/y' and 'overflow-style' (as per issues 4,5,7, and 9 in the spec), then I think the choice should be obvious. 'overflow-x/y' are too well established in the minds of authors, and just need to remain in this spec. I don't think we can make them go away in any reasonable manner.

For paged overflow, it simplifies the number of properties too. We can just have 'overflow-x: paged' and 'overflow-y' paged. The author can decide with 'scroll-coordinates' what that means. 

Some related thoughts on paged overflow:

* I don't see why we need the '-controls' suffix for the value. The UA should provide the controls automatically, as it does for 'scroll'. If the author wants to provide his own controls that use JavaScript, then he should be able to also use JavaScript to suppress the UA controls (and there should be a hook allowing him to do that). 

* pages should be fragmentable or scrollable in the inline direction if the author wishes. What I mean is that I should be able to say 'overflow-y: paged; overflow-x: paged;', and whatever overflowed in the inline direction would be sliced into pages. This would allow allow a 2D grid of pages, if the container had multiple 100% width articles laid out side by side in it. Similarly, with 'overflow-y: paged; overflow-x: auto;', whatever overflowed in the inline direction would be visible via a scroll bar.

Received on Saturday, 6 April 2013 23:47:51 UTC