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

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

> Brad Kemper wrote, in a long message,
> 
>>> 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.
> 
> I think this is a seminal point, one that perhaps explains the
> different proposals.
> 
> You are right in pointing out that the "2D physical layout" is only
> one of many ways of presenting a page change. I'd like for the web to
> support all of the above methods, and also the one used by Wired where
> the next/previous article is found on the right/left, and the
> next/previous page is found below/above.
> 
> I may be that all we need is a property like:
> 
>  overflow-paged-effect: none;             /* not paged */
>  overflow-paged-effect: vertical;         /* wired */
>  overflow-paged-effect: instant;          /* kobo */
>  overflow-paged-effect: curl;             /* ibooks */
>  overflow-paged-effect: horizontal;       /* economist, nytimes ++ */
>  overflow-paged-effect: horizontal fold;  /* flipboard */
>  overflow-paged-effect: filter(...);      /* something else */
> 
> This way, we could leave the 'overflow-x' and 'overflow-y' properties
> alone, they could continue doing what they do.

I think it is important to separate the question of "which axis of content overflow are we going handle in this declaration" (which is what 'overflow-x' and 'overflow-y' do) from the question of "what is the special effect/UI-variation going to be for paged overflow". That way, authors can get a UA/OS appropriate effect/behavior on a vertical overflow by simply saying 'overflow-y: paged'. And since horizontal overflow often does exist, the author should still be able to chose how to handle it via 'overflow-x: hidden | scroll | auto | paged' (visible would become hidden if the other axis is paged, just as it does when the other axis is scroll or auto). 

Other than that, I'm not too opposed to 'overflow-paged-effect' or whatever we call it, in addition to 'overflow-*: paged', although then we wouldn't need 'overflow-paged-effect: none' (or maybe none is the instant transition, and we don't then need 'overflow-paged-effect: instant').

>> 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.
> 
> Using the above property, we wouldn't have to say anything about
> gestures, buttons or how to get to the next page. The property would
> just spcify what happens when the page shift occurs. Is this
> compatible with your views?

Generally, yes. The behavior should automatically be what is appropriate for the effect. The property should also include an 'auto' value, which would be the initial value, allowing the default UA/OS appropriate effect/behavior. 

> So far we have mostly talked about page shifts within a document. I
> also think we need to discuss how to do page shifts to the other
> documents; this is necessary in order to replicate Wired and The
> Economist.

I'll just point out here that AJAX would allow this. The next chapter could be loaded via AJAX whenever the current page is turned to, or you could have a blank page for each chapter, and load new content into that page after you turn to it. 

But I do agree it would be nice to have page transitions for "normal" new HTML page loading. 

> GCPM sketches a way to layout documents spatially:
> 
>  <link rel=index href="../index.html">
>  <link rel=previous href=g3.html>
>  <link rel=next href=g1.html>
> 
>  @layout {
>    nav-up: go(index); 
>    nav-left: go(previous); 
>    nav-right: go(next); 
>  }
> 
> Please tell me you like it :)

Umm. Well, I like the idea of using the link rels. But the problem is that the 'nav-up' etc. is too tied to the 2d layout of pages. I'd like to have html-page-to-html-page transitions that were not necessarily dependent on that particular way of visualizing where the pages are. I don't see how it would work if you wanted a page curl animation to the next page. Also 'go()' appears to be doing more than styling. I think you'd be better off with something like this:

:root:location {
    /* something is paged, not really an element overflow */
    page-transition: curl;
}

Or maybe '@location' is the selector. 

Then you'd get the same sort of controls as for things with that setting and 'overflow-y: paged'. So, flip the lower right corner and you go to the 'rel=next' URL, flip the lower left corner and you go to the 'rel=previous' URL. 

I don't know how that would work with 'body { overflow-y: paged; }'. Perhaps you page to the end of body, and then one more page flip to get to next URL page. 

It still seems like a little more than just styling, but not as much, and it is really the  <link rel=next> and  <link rel=previous> controls that are being styled with the effect and UI behavior.

Received on Friday, 26 April 2013 04:36:26 UTC