Re: Paged UIs a la Mobile Navigation

Anyone have any feedback?

Yehuda Katz
(ph) 718.877.1325


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.
>
> Yehuda Katz
> (ph) 718.877.1325
>