W3C home > Mailing lists > Public > www-style@w3.org > January 2014

Re: [css-snappoints] CSS Snappoints feedback

From: Robert O'Callahan <robert@ocallahan.org>
Date: Thu, 30 Jan 2014 14:04:25 +1300
Message-ID: <CAOp6jLZvZdP3XLjgf5zDQ0fdqK+W5TSPiCmPiDBLgGP6tZn55Q@mail.gmail.com>
To: Matt Rakow <marakow@microsoft.com>
Cc: "www-style@w3.org" <www-style@w3.org>
On Thu, Jan 30, 2014 at 1:37 PM, Matt Rakow <marakow@microsoft.com> wrote:

>  Regarding why the updated version is different from the element-snapping
> proposal on the Mozilla wiki, there are a number of scenarios that proposal
> is unable to solve.  These include the two scenarios I mentioned in my mail
>

Which are, FTR,

> a) Snapping an element to the center of a scroller (instead of the edge)
> b) Snapping an element to some offset from the edge (e.g. next/previous item "peeks" to show the user there is more content)
>
>
#a is difficult to talk about at the moment because we don't have a shared
understanding of how snapping works when scrolling in different directions.
But I think it could be easily solved with scroll-snap-edges by adding an
optional "center" keyword.

#b can also be easily solved with scroll-snap-edges by adding an optional
<length> value (or 1-4 values like for padding/margin properties)
specifying offsets extending outside the box.

as well as additional complex scenarios that need consideration, raised by
> others in the face to face today:
>
> 1) Diagonally positioned snappable elements in a 2d scroller, for example
> snapping to center on cities on a map
>
> 2) Freely scrolling areas within “boundaries” that resist scrolling
>
 3) Elements with multiple snap points (relationships of 1 element to many
> snap points), for example a single large image with many points of interest
> to focus on
>

It seems to me #3 and #1 could be handled using scroll-snap-edges with
invisible elements representing the points of interest. Also they could be
adequately handled via script. We need to limit the scope of this feature
somewhere.

To handle #2, IIUC, we need to be able to declare continuous intervals of
possible snap destinations instead of just individual points, something
that no proposal yet does, but it's pretty easy with either proposal.

  This draft is still very much a work in progress – I don’t mean to give
> the impression that feedback will not be addressed if it wasn’t addressed
> in this initial update.
>

OK thanks.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w
Received on Thursday, 30 January 2014 01:04:52 UTC

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