Re: Paged UIs a la Mobile Navigation

On Nov 22, 2011, at 8:22 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Mon, Nov 21, 2011 at 10:11 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> On Nov 21, 2011, at 6:57 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>> I think this a reasonable sort of thing to support.  Further, it's
>>> clearly within the same general area as Hakon's recent proposal about
>>> paged overflow.
>>> 
>>> However, there doesn't appear to be any reasonable way to support this
>>> kind of thing within the currently exposed paged overflow primitives.
>>> This suggests to me that we need to look at the primitives again and
>>> design something a little more general, which overflow can then hook
>>> into.
>>> 
>>> I'm not immediately certain what those primitives should be, but it
>>> sounds like a valuable thing to look into.
>> 
>> Call me stupid, but I don't understand what you're talking about. Primitives? What is it that Håkon's proposal doesn't cover? Is it something about embedding one overflow:paged inside another? Or is it about combining scrolling and paging in the same element? Yehuda's comments about hardware acceleration of scrolling seems kind of unrelated to paged overflow with visual effects.
>> 
>> For what it's worth, I would hope that a UA implementing paged overflow would include some sort of UA-standard effect like a page curl, and that there might be some alternative transition effects that the author could choose (although it is bad for the user if there are too many ways to turn a page).
> 
> I'll back up a bit.
> 
> Hakon's proposal for paged overflow is just that - when you have some
> overflow, you generate additional pages within the element and put it
> there.  Overflowing is the only way to generate pages.
> 
> Yehuda's message was about using something page-like explicitly as a
> layout effect, where each container lives on a "page" and you flip
> between "pages" when manipulating the UI.  This visual pattern is used
> a lot in iOS apps and sometimes in Android apps, and looks rather
> nice.

So if you wanted some content to be paged and to be five pages long, you'd start with five DIVs (or SECTIONs or whatever), and set each one to page break after (and not break within), then put all five divs to be height:100% and put them into a container that is overflow:paged. Each of the five divs could be overflow:auto, so that you could scroll it separately, but you would use the paged overflow of the container to move between pages. 

If you wanted the content to divide up more naturally as a flow (not based so much on its internal structure), without the need to scroll each independently, then don't bother with the five divs. The container still has overflow:paged, so whatever doesn't fit in its constrained height will be available as additional pages. 

Either way, the UI for moving between pages could be anything from arrow keys to instantly switch between "pages" (on some simple, very underpowered, low-end UA) to gesture based animated page curls (on something like iBooks on iOS). 

So, I am already imagining 'overflow: paged' as probably resulting in something rather nice where you flip between pages when manipulating the UA. And I am imagining that as the UA having a default way to turn pages (I'm fond of the iBooks way), but to also allow something like overflow-style to pick alternated (such as the flatter gesture based animated page flips of Flipboard). 

Maybe overflow-style isn't the right thing for picking that, maybe 'page-transition-style' is better. Thus 'page-transition-style: curl' would play a 1 second curling animation on a desktop when you press the right arrow key, but would be a curling animation that followed your finger when you swiped it leftward from the right edge of the container on the iPad (like page turning works in iBooks). At the CSS level you are still just using some UA-provided UI (input with visual feedback) to access overflowed content, with 'page-transition-style' being akin to the styling of scrollbars in the 'overflow: scrolled | auto' corollary. 

>  Yehuda then provided some extra detail about why it's difficult
> or impossible to performantly/attractively do this UI with the
> existing primitives that CSS exposes - you don't want to trigger
> hardware acceleration on normal scrolling, but you *do* on sideways
> translations (the "page flips"), and switching between hw-acc or not
> produces a visible flicker.

I don't really understand that problem. Is it really impossible to hardware accelerate a page flip animation without messing up normal scrolling? I don't know why this would be the case. Yehuda seemed to be talking about hacks that authors use to activate acceleration today, but I don't see how that would be relevant to the UA handling it more gracefully.

Received on Wednesday, 23 November 2011 06:47:26 UTC