Re: Paged UIs a la Mobile Navigation

On Nov 21, 2011, at 6:57 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

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

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

Received on Tuesday, 22 November 2011 06:12:14 UTC