W3C home > Mailing lists > Public > www-style@w3.org > November 2011

Re: Paged UIs a la Mobile Navigation

From: Andrew Fedoniuok <news@terrainformatica.com>
Date: Tue, 22 Nov 2011 21:55:13 -0800
Message-ID: <BLU165-ds5599751ACAB5D427778ACF8C90@phx.gbl>
To: "Yehuda Katz" <wycats@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
CC: "Brad Kemper" <brad.kemper@gmail.com>, <www-style@w3.org>
I suspect this discussion is about position:popup; that I am using.
position:popup is pretty much position:fixed but UAs is allowed to create special popup window
for such an element. Examples of such popups: 
  a.. “rich tooltips” like http://www.terrainformatica.com/htmlayout/images/tooltip-balloon.jpg 
  b.. dropdown lists in <select>s; 
  c.. popup menus; 
  d.. iPad alike popover panels - popup windows with active elements. 
  e.. MS Office alike context toolbars and menus.
Are these close to the subject?


-- 
Andrew Fedoniouk

http://terrainformatica.com



From: Yehuda Katz 
Sent: Tuesday, November 22, 2011 9:15 AM
To: Tab Atkins Jr. 
Cc: Brad Kemper ; www-style@w3.org 
Subject: 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
Received on Wednesday, 23 November 2011 05:55:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:46 GMT