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

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

> Hello Brad,

Hi!

On Apr 9, 2013, at 3:34 PM, Håkon Wium Lie <howcome@opera.com> wrote:
> 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.

But I would think if one thought that scrolling/flipping/turning to the next page should be vertical for western languages, due to the way scrolling works now to advance in the page progression direction, then one would also desire that same logic to apply to vertical writing. I guess the author could change overflow and page-progression at the same time, but it seems like it would be better if it was automatic. 

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

I think that designers shouldn't have to make that choice in order to get paged overflow. And I think it is bad for users if every Web document with paged overflow has a different mechanism for getting to the next page. If one gesture is for the next page in one document and for next chapter in another, and vice versa, then I think that is generally bad for overall usability. One of the things that makes scrollbars easy to use is that they work consistently throughout the OS. Think about how Apple reversed the way scrollbars worked in OS X 10.7. People had to get used to it, but it would have been worse if every web author were to choose how those scrollbars worked.

> And they don't need all four directions. That is, designers don't need
> to position successive LTR pages towards the left.

Agreed.

>>> 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 x or y of what aligns with the z-axis? Once you have a stack of pages, the only thing you are aligning on the 2D plane is the gesture and special effect used in the transition from one page to the next. But some transitions in some UAs are just a quick fade or an instant reveal, and the mechanism for turning might just be clicking on physical device buttons or using a voice interface. In these cases, page-x and page-y are meaningless, but overflow-x and overflow-y are still meaningful and useful.

> The the vast majority of paged media is formatted this way. The
> exceptions are minor: spreadheets (sometimes) and the
> print-poster-applications.

And yet we handle horizontal overflow in CSS 2.1, with scroll, auto, or hidden. I find it surprising that (I think) you would have it always hidden once the element paged in the vertical dimension. 

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

It should be obvious that I want to let authors choose between the two, so I guess you are asking if I want CSS to be able to express a preference for how scrollbars should work for continuous presentations, and for how page traversal should work for paged presentations. And my answer is the same for paged as for continuous: it should not be CSS's priority to aid in creating user interface confusion. There are those who hide scrollbars with 'overflow:hidden' and then bolt on some JavaScript and buttons/links to create their own scrolling UI. That's fine if someone wants to go to such extents to create non-standard UI, and I think a similar level of JavaScript access should exist for paged overflow too. 

At the most, I think there should be a separate property for declaring the intent of how the user interface should work for traversing the pages. That way, those who want that level can have it, and it can be extended in the future with new ways to transition between pages. But those who just want to create paged presentations using the OS or UA standard can do so by declaring 'overflow[-x | -y]? : paged'. 

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

I think what I have described would still make it easier to accomplish on the Web (through JavaScript or a separate property like 'page-transition') than it would be through C# or Objective-C. In fact, I suspect Flipboard might be using existing CSS transforms for what it is doing inside its app wrapper.

(PS. Sorry that I referred to Flipboard as "FlipBook" previously. My bad.)

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

Apps sometimes do that. Other times they use a dissolve (Kobo), or a page curling effect (iBooks, etc.), or a perspective transform (Flipboard), or a sliding off effect (Overdrive), or even just an instant reveal (Kobo option). I don't see any reason why we need to prioritize a push-in-from-edge effect over the others, and then make the author choose one of the two variations of that effect in order to get paged overflow.

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

Great!

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

It could be a competitive advantage then, if you did do better than the other implementors. Personally, I never tire of the page flipping UA of iBooks and others. Flipboard is pretty great too; it's less skeuomorphic, but otherwise kind of similar.

> And I'm certain that authors will think they are
> uniquely qualified for the job :)

I think I am pretty good as a Web author and designer, but I'm pretty sure it would take more than overflow:page-x to create an effect as good as iBooks' page turning effect tied to a page turning gesture. It might be an interesting challenge, with JavaScript and CSS shaders and such. But I think it would be better to have that just available as a built-in effect though (either standard for the UA, or chosen in a separate property from a list of effects/interfaces), so that I could be more productive at other parts of my 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.

That's a bit over the top, Håkon. You know I am a big fan of CSS styling and giving stylistic power to authors. I just happen to also be a fan of usability. 

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

No more troublesome than trying to have scroll in the x direction and visible in the y. It just ends up being the same as hidden (it could be actually be visible when overflowing a page box on the screen, without the absolute constraints of physical paper size). But with overflow-x: paged, the horizontal pages can be added to the stack, so they aren't lost. And there should be no insurmountable problems combining horizontal scrolling with vertical paging (even if it used the same gesture in touch interfaces to scroll or to flip, that's no worse than having one scrollable area inside another: you just pull the overflow all the way to the left before you flip the page). 

> In paged enviroments, it may be better for force content to stay
> within limis, even if it involves overriding 'white-space' or scaling
> images.

I am really surprised at that attitude. Horizontal scrolling is very useful in a lot of situations, and I think horizontal paging would be too. If things are currently not being printed when they are too wide for one page, then I definitely feel that this a ripe area for improvement.

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

And each app can be thought of as a single UA. How many of them change the method of accessing next pages based on what book/magazine/article/whatever is being read?

> I'd like to be able to code those native apps in HTML/CSS.

I don't see having two axes of push-in effects, instead of one "standard" effect or multiple fancier effects, as opening up brave new worlds or bringing CSS up to par with what apps do.

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

It feels a little short sighted to me. I think a UA could have better form of UI than that. It could evolve with new versions, as one page traversing effect starts looking dated. But the usability is improved if there is a standard, even if it is only a UA standard and not OS-wide.

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

Safari remembers my scroll position when I back-button to a page, but starts out at the top for new pages. I could see overflow into a 2 dimensional grid as working the same way: scroll me up to the top of a column of pages if I am moving into the column for the first time, otherwise auto-scroll to me to where I was before vertically. A smart UA would know when to be able to do this pretty easily, given that is is basically very similar to a scroll anyway, that snaps to page edges.

This is assuming something like 'page-transition: push-in' to fit your general concept of how 'overflow: page-y' transitions between pages, and with separate controls or gestures for accessing the overflow-x and the overflow-y. 

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

Yeah, it just scrolls up to where there is actually a page, or to the top. Why not? The UA knows that it has created a grid of pages, regardless of the CSS that got it there, and it knows what page you are on or have been to at any one time, so it can be smart about what page it takes you to in that case. It might behave a little differently if it was one giant image or something (not just text) spanning columns and rows both. For that you probably wouldn't want to jump to the top of the column. 

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

It might depend on the UI. For instance, if it is a page curl from the right to get to overflow-x (for the next page of the article), and a push in from the bottom to get to the overflow-y (to get to the next chapter), then this grid of pages would probably work better than having each chapter run vertically. You might need a 'page-transition' property to make a good choice at that point.

On the other hand, if the UI was to just put all pages on the z-axis, regardless of if they came from overflow-x or overflow-y, like when you print a large spreadsheet to a physical printer, and they could just fly off the stack in whatever direction you flicked your finger, then it wouldn't matter much which direction you chose for your in-chapter overflow.

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

I'm not sure I follow. I think there are several opportunities for improving the way UAs print though.

Received on Saturday, 13 April 2013 06:43:54 UTC