Re: Paged UIs a la Mobile Navigation

The use-case for this on desktop would be something like an iPad popover,
where you'd get a container that mapped onto a phone screen taking up only
part of the screen.

Yehuda Katz
(ph) 718.877.1325


On Tue, 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.  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
>