Re: CSS properties for snapping during scrolling

Robert O'Callahan wrote:

 > On Fri, Aug 16, 2013 at 12:28 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:
 > 
 > > On Thu, Aug 15, 2013 at 5:20 PM, Robert O'Callahan <robert@ocallahan.org>
 > > wrote:
 > > > Could we support both physical and logical properties and values here? I
 > > > think we could. So scroll-snap-edge values could be "none | [ left ||
 > > > margin-left || top || margin-top || inline-start || margin-inline-start
 > > ||
 > > > block-start || margin-block-start ]". (I've wondered whether
 > > > "end"/"right"/"bottom" values would be useful as well, but I haven't
 > > though
 > > > of a need yet.)
 > >
 > > I see no reason why you *ever* want physical snapping.  When you would
 > > want an element to snap in the block axis in a horizontal language,
 > > but in the inline axis in a vertical language?  That's what "vertical"
 > > means, after all.
 > 
 > In the FirefoxOS home screen use-case, we will never want the home screen
 > to scroll vertically, and I don't think we would reverse the order of the
 > home-screen pages in RTL languages either. In such cases, having to use
 > logical properties is just unnecessarily confusing.

At Opera, we considedered this when implementing paged overflows. I
worked my way through a number of apps that use paged presentations.
We found that writing mode had little to do with how pages were
laid out. For example, one app shows pages laid out to the right in
their tablet app, and pages laid out downward in their phone app. One
magazine uses both right and downwards in the same issue. It seems to
be a design choice based on other factors than language. 

So, I agree that referring to horizontal/vertical makes most sense. 

(However, which direction along the chosen axis content/pages are laid
out, can be derived from the writing mode.)

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Friday, 16 August 2013 02:41:47 UTC