- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Thu, 30 Jan 2014 14:04:25 +1300
- To: Matt Rakow <marakow@microsoft.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
- Message-ID: <CAOp6jLZvZdP3XLjgf5zDQ0fdqK+W5TSPiCmPiDBLgGP6tZn55Q@mail.gmail.com>
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