- From: Yehuda Katz <wycats@gmail.com>
- Date: Thu, 3 Nov 2011 12:06:01 -0700
- To: www-style@w3.org
- Message-ID: <CAMFeDTU0j1d5DeGz5-G1gV9hwjwZ9JMBPHp3gBybE6MYqkaA_g@mail.gmail.com>
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
Received on Thursday, 3 November 2011 19:06:56 UTC