W3C home > Mailing lists > Public > www-style@w3.org > April 2013

Re: [css-overflow-3][css3-marquee][css3-gcpm] x/y directions (maybe [css3-break] too)

From: Håkon Wium Lie <howcome@opera.com>
Date: Thu, 25 Apr 2013 21:28:17 +0200
Message-ID: <20857.33745.924979.510002@gargle.gargle.HOWL>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: www-style list <www-style@w3.org>
Brad Kemper wrote, in a long message,

 > > True. But tablets routinely turn the z axis into x or y.
 > Apps sometimes do that. Other times they use a dissolve (Kobo), or
 > a page curling effect (iBooks, etc.), or a perspective transform
 > (Flipboard), or a sliding off effect (Overdrive), or even just an
 > instant reveal (Kobo option). I don't see any reason why we need to
 > prioritize a push-in-from-edge effect over the others, and then
 > make the author choose one of the two variations of that effect in
 > order to get paged overflow.

I think this is a seminal point, one that perhaps explains the
different proposals.

You are right in pointing out that the "2D physical layout" is only
one of many ways of presenting a page change. I'd like for the web to
support all of the above methods, and also the one used by Wired where
the next/previous article is found on the right/left, and the
next/previous page is found below/above.

I may be that all we need is a property like:

  overflow-paged-effect: none;             /* not paged */
  overflow-paged-effect: vertical;         /* wired */
  overflow-paged-effect: instant;          /* kobo */
  overflow-paged-effect: curl;             /* ibooks */
  overflow-paged-effect: horizontal;       /* economist, nytimes ++ */
  overflow-paged-effect: horizontal fold;  /* flipboard */
  overflow-paged-effect: filter(...);      /* something else */

This way, we could leave the 'overflow-x' and 'overflow-y' properties
alone, they could continue doing what they do.

 > I think that designers shouldn't have to make that choice in order
 > to get paged overflow. And I think it is bad for users if every Web
 > document with paged overflow has a different mechanism for getting
 > to the next page.

Using the above property, we wouldn't have to say anything about
gestures, buttons or how to get to the next page. The property would
just spcify what happens when the page shift occurs. Is this
compatible with your views?

So far we have mostly talked about page shifts within a document. I
also think we need to discuss how to do page shifts to the other
documents; this is necessary in order to replicate Wired and The
Economist. GCPM sketches a way to layout documents spatially:

  <link rel=index href="../index.html">
  <link rel=previous href=g3.html>
  <link rel=next href=g1.html>

  @layout {
    nav-up: go(index); 
    nav-left: go(previous); 
    nav-right: go(next); 

Please tell me you like it :)

              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Thursday, 25 April 2013 19:28:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:28 UTC