Re: Paged UIs a la Mobile Navigation

On Thu, Nov 3, 2011 at 12:06 PM, Yehuda Katz <wycats@gmail.com> wrote:
> I'd like to get some feedback on whether we could have explicit way in CSS
> to describe the type of UI that mobile devices use for navigation or
> hierarchy, but which also figure into popovers on tablet or desktop devices.
> The basic idea is:
>
> A container element of this type could have several child elements, only one
> of which could be presented on screen at once.
> When a child element is on screen, it can scroll using the normal scrolling
> mechanism, but the container element never scrolls.
> The container can transition to an element to its left or right. After
> transitioning, the new element retains its last scroll position (the initial
> scroll position is top).
> Transitions should be regular CSS transitions, and possibly some additional
> conveniently defined transitions, like "pan" or "fold"
>
> It is possible to get close to this on some browsers, but because hardware
> acceleration figured prominently into making this experience performant, and
> because hardware acceleration is only indirectly exposed to the author,
> making this work reliably across all browsers is, at present, impossible.
> This is partially addressed on iOS via -webkit-overflow-scrolling.
> One major area of remaining concern is that, in general, it is inadvisable
> to make scrolling elements hardware accelerated (using one of the transform
> hacks) because it creates a worse scrolling experience (significantly more
> tiling), but horizontal transitioning is only performant on mobile devices
> when working against an accelerated element. Transitioning an element to
> accelerated (by beginning a 3d transform, for instance), reliably produces
> an undesirable flicker.
> In short, the browsers are in a much better position to make this
> interaction performant than authors, who need to devine performance
> characteristics on a per-release, per-browser basis, and a performant,
> flicker-free solution is often not possible at all.

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.

~TJ

Received on Tuesday, 22 November 2011 02:57:49 UTC