Re: Paged UIs a la Mobile Navigation

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

There's a possibility that we can expose lower-level details of
Hakon's proposal (the generation and turning of pages) more directly,
to easily address Yehuda's case and perhaps others.


Yehuda, I have a question.  The paged uis you speak of generally have
pages of varying heights.  The page-flip transition always looks fine,
though, because you never see a ragged edge get turned - the "page"
always fills the entire screen (with possibly some fixed elements
sitting on top).  How do you imagine this working on the desktop,
where each "page" would be only a portion of the screen?

~TJ

Received on Tuesday, 22 November 2011 16:23:49 UTC