- From: Håkon Wium Lie <howcome@opera.com>
- Date: Sat, 13 Apr 2013 01:12:08 +0200
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: www-style list <www-style@w3.org>
Hello Brad,
> 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.
Indeed, there seems to be two modes.
> > 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).
Yes.
> 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?
Sorry, I mis-typed. I meant to say that I hadn't found any
*LTR*-language pages being laid out towards the left or upwards.
Therefore, my conclusion is that we only need two values: x and y
which means that the next page is positioned as follows:
RTL LTR
x left right
y down down
> > 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?
Yes. The horizontal vector points from right to 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'?
The vertical vector is downwards in both cases, so successive pages
would appear under.
> >> 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.
I think we're in agreement on this; the number of pages that use
vertical vs. horizonatal may differ, but designers need those two
choices.
And they don't need all four directions. That is, designers don't need
to position successive LTR pages towards the left.
> >> 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.
Indeed there is software that does 2D grid-like layouts to make
posters. But that's a niche application meant to compensate for a lack
of a large-format printer. We could define a system to compensate for
a lack of a large tablet.
But that's not what the 'overflow: paged', as formulated in GCPM, is about.
Overflow: paged is a about electronic books. The proposed model that
(a) the formatter lays out the document along a z-axis. Thereafter (b) the
value on overflow (or overflow-style) describes which axis are aligned
with the z-axis: either x or y.
The the vast majority of paged media is formatted this way. The
exceptions are minor: spreadheets (sometimes) and the
print-poster-applications.
> > 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.
So, you don't want CSS to express preferences for continous or paged
presentations?
I think we should allow CSS to express this -- to be used by both
authors, users, and UAs. Authors do this routinely in Apps, an if it's
lacking from the web, they will go somewhere else.
> 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.
True. But tablets routinely turn the z axis into x or y.
> 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.
This could work.
> 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.
I'm not convinced that we -- or UA implementors -- are able to design the
best user interfaces. And I'm certain that authors will think they are
uniquely qualified for the job :) Just like they thought they could
pick better fonts and colors than the ones hard-coded into Mosaic in
the begninning. Mosaic provided a "standardized" user interface, but
it became boring after a while.
> 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.
On a side note, 'overflow-x' is troublesome when printing -- how do you
support 'visible' (by putting chopped-off lines/images on separate
pages at the end?) or 'scroll'.
In paged enviroments, it may be better for force content to stay
within limis, even if it involves overriding 'white-space' or scaling
images.
> >> 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.
I can see that being an issue. Most native apps choose something
sensible, though. I'd like to be able to code those native apps in HTML/CSS.
> 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.
Where we differ, I guess, is the definition on "monkey". I believe
that changing the axis of navigation from horizontal to vertical is a
reasonable thing to do, and not somthing that will cause users much pain.
> >> * 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).
I can see the use case: I'd like to have a complete book in one
HTML file and move in chapters along one axis and pages along the
other.
But I'm not sure the user interface would be pleassant. If chapters
have different lenghts (they do) many of the cells in the grid will be
empty. How do you stop the user from getting lost in a sea of blank
pages? One way would be to only allow navigation to pages that have
content. In this case, moving right and then back left left may take
you to a new place. Hmm.
> 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>
Hmm. It doesn't strike me as intuitive. Could we achieve the same by
splitting a document into several "strips" (as opposed to only one
strip, which is how documents are printed normally?
-h&kon
Håkon Wium Lie CTO °þe®ª
howcome@opera.com http://people.opera.com/howcome
Received on Friday, 12 April 2013 23:12:40 UTC