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

Håkon, thanks for responding. I was beginning to wonder if anyone had read what I wrote.

On Apr 9, 2013, at 3:34 PM, Håkon Wium Lie <howcome@opera.com> wrote:

> 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 agree that horizontal or block directions can both be reasonable choices. It just seems to me that if an author (or implementor) chose the inline direction, it would be to be more "book-like", whereas the reason to choose block direction would to be more like scrolled content, where additional content can be found by continuing "down" the page to another page, in the direction your eye is moving as you consume lines of text. iBooks has a mode like this, where each new chapter is a long page located under the previous one.

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

Sure. So if the UI had two modes, as iBooks does, where horizontal represents a book-like turning or revealing of pages, and the other one a mode where one page follows the other as though laid end-to-end, then I would expect the second mode to lay out the sequence in the block progression direction (as iBooks does in the English-language books I read). 

I haven't actually seen an iBooks in a language that uses horizontal left-to-right block progression, but if there were any the second mode would be pretty strange if each chapter had different very long widths, with each one under the other, and you'd have to slide everything up  to get to the next chapter and slide the right side back into view to actually start reading that chapter. And even if they were side by side, it would be awful to read a whole chapter progressing from right to left, but then have to slide back to the beginning of the chapter to go to the next chapter on the right.

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

Due to Western bias of the tool-makers and/or publishers, perhaps? Further perpetuated into Opera now?

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

Do you mean that if I have a vertical writing mode, say 'writing-mode: vertical-rl', and I have 'overflow: paged-x', then the successive pages would appear on the left? Or do you just mean that with 'writing-mode: vertical-rl', and 'overflow: paged-y', the successive pages would appear under the previous ones, same as with 'horizontal-tb'?

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

Well, I think it would be more accurate to say the swiping direction for the other half is from the right, no? In the default modes for iBooks, Kobo, and Overdrive, for instance, the pages are underneath, not to the right. But that is fine, my example just referred to one of those choices (vertical block progression layout), and how that choice should work.

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

If there is overflow in the other axis too, I don't see any reason why that can't also be sliced into pages. Scroll works in 2 directions, why not paging? Back in the day when I designed poster-sized stuff in Adobe Illustrator, it was a simple matter to tile the large art board into a grid of letter-sized pages. For the inline direction, I would have just such slicing.

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

I wouldn't. Just as I do not pick scrollbar style for 'overflow:scroll'. I do not decide to put scrollbars on the top and left, or decide if the two buttons on each bar should be together on one end or one on each end. The UA should have standard UI for getting to to the next page, and it should not change based on an author's whim (I say this as an author, by the way). Standardized UI is important.

The notion of pages being arranged vertically or horizontally seems weird to me actually, given that real books have them stacked in the z-axis. The exception would be inline-direction overflow, where it would be more natural to want to see the pages side by side (scrolling in that direction would be even more natural, though, honestly)

So here is how I would see overflow:paged working, if I were the UI designer for the UA (or OS): if there was 'overflow-y: paged' (which would really mean something like 'overflow:page-progression-direction: paged'), then the AU would have a standard mechanism for getting to the next page of content. This would probably be a page flipping gesture (or click on a dog-eared corner with my mouse), with accompanying animation of the next page being revealed under the current one. 

If there was also overflow in the inline direction, then the value of 'overflow-x' would determine how that is handled (which it does today, without paged overflow). If it was 
'overflow-y: paged; overflow-x:paged', then a right-to-left swipe on a tablet would slide the sliced off right side, and another swipe would flip over to the next block-progression page. Maybe swiping diagonally from the bottom right would allow you to bypass the inline-overflowed page. 

But that's all just implementation detail. If you, as implementor, wanted the pages to appear as though they were all carefully glued down to a giant scroll, either vertically or horizontally (pick one, and stick with it), so that every time you moved the scroll the glued down page would snap to the edges of the port, that's fine. Just please also handle the inline overflow according to the overflow-x setting.

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

I'd hate to make it too easy for authors to make users learn new controls every time there is paged content.

My point is that, as with standard scrollbars, the author shouldn't need to ever choose the UI for either scrolling or paging. But there will always be some people who will want to monkey with it to get a really custom effect, and (as with scrollbars) this can be done with links and buttons and JavaScript.


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


Really? OK, I'll try an example. Imagine a small magazine being printed at a printing company, with every page printed together on an enormous sheet before being cut into pages and bound. Now imagine for the sake of argument that each of the columns of this grid of pages is one chapter. We recreate that in HTML and CSS with something like the following:

<body>
     <article>entire article text [...]</article>
     <article>entire article text [...]</article>
     <article>entire article text [...]</article>
     <article>entire article text [...]</article>
     [etc]
</body>

<style>
body { 
width: 1vw; 
height: 1vh;
margin: 0;
overflow-x: paged /* UA lays out horizontal overflow similar to your paged-x, in side-by-side pages with only one showing at a time */;
overflow-y: paged /* UA lays out horizontal overflow similar to your paged-y, in bottom-by-top pages with only one showing at a time */;
}
article {
width: 1vw;
display: table-cell;
Padding: 16px;
}
</style>

This should create a situation where swiping horizontally lets you switch chapters, and swiping vertically lets you switch pages within a chapter (assuming the UA lays out pages similarly to your concept of paged-x and paged-y). 

To reverse that, and have vertical swiping to change chapters and horizontal swiping to change pages within chapters, you could do something like this:

<style>
body { 
width: 1vw; 
height: 1vh;
margin: 0;
overflow-x: paged /* UA lays out horizontal overflow similar to your paged-x, in side-by-side pages with only one showing at a time */;
overflow-y: paged /* UA lays out horizontal overflow similar to your paged-y, in bottom-by-top pages with only one showing at a time */;
}
article {
height: 1vh;
column-width: 1vw;
column-gap: 0;
page: articlepage
}

@page articlepage { margin: 16px; }

</style>

Received on Wednesday, 10 April 2013 16:20:37 UTC