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

Brad Kemper wrote:

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

At Opera, We considedered this when implementing paged overflows. I
worked my way through a number of apps that use paged presentations.
We found that writing mode had little to do with the way pages were
laid out. For example, one app uses pages laid out to the right in
their tablet app, and pages laid out downwared in their phone app. One
magazine uses both right and downwards in the same issue. It seems to
be a design choice based on other factors than language.

So, at least for western text, it seems that both the inline and the
block direction are natural choices.

I would expect the same to be the case in RTL languages: left and
downwards would be equally natural.

I could not find any examples of RTL-language pages being laid out
towards the left or upwards.

The keywords we ended up supporting reflect this: 'paged-x'
automatically lays pages out in the writing direction on the
horizonaltal axis, while 'paged-y' automatically lays pages out in the
writing direction along the vertial axis.

As such, the values are sensitive to the writing mode.

 > 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 seems that half the apps do it this way, the other half give you
the next page on the right.

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

To me, it doesn't make sense to set 'paged' values on overflow-x/y --
you can't page one axis, you have to page the whole document. One can
either use 'overflow' for that, or 'overflow-style' (I don't have a
strong opinion).

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

In your proposal, how would I set this: 

  html { overflow-style: page-x }

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

You could use JS for that, but it's a basic declaration and our job
is, BTW, to get rid of JS :)

The current proposal is modeled on the 'controls' attribute on the
<video> element in HTML.

In most paged examples I've written, I don't expose controls. I'd hate
to have to put JS into the examples to remove the controls. 

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

Hmm. I don't see how you can page in one direction and not the other.
In my mind, the document is either paged or not.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Tuesday, 9 April 2013 22:35:18 UTC