[css-snappoints] CSS Snappoints feedback

Hi Robert,

I'll definitely be addressing more feedback in future revisions.  However, this update was primarily addressing the alternative approach to element-based snapping that I alluded to in my reply to your feedback (http://lists.w3.org/Archives/Public/www-style/2013Dec/0303.html).  Many of the points you raise below came up during discussion at the face to face today as well, and I'll be focusing on them in the coming weeks.

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 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

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.

Thanks,
-Matt

>From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
>Sent: Wednesday, January 29, 2014 3:24 PM
>To: www-style
>Cc: Matt Rakow
>Subject: CSS Snappoints feedback
>
>I'm a bit concerned about the way this spec is being developed. I provided substantive feedback in this email, along with a variant proposal: http://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html
>There was very little discussion, and now I've found out that the spec has been updated taking practically none of my feedback into account: http://dev.w3.org/csswg/css-snappoints/
>I thought we generally try to address email feedback in email and reach some kind of consensus (or at least a consensus that there is no consensus) before we update drafts.
>Anyway, here is some feedback about the new draft. I hope it's not ignored again.
>1) Independent control of scroll-snap-type for vertical and horizontal axes is essential. Imagine, for example, you're scrolling through a vertical list of images of different sizes and some of them overflow horizontally. We want to snap to image edges when scrolling vertically but do no snapping when scrolling horizontally. With the current draft we can't do that.
>2) I'm not sure that scroll-snap-points-x/y is really needed if we have good support for scrolling to element edges. Is there a use-case where it's useful to be able to specify snap-points that are not at the edge of some element's box (or some fixed offset thereof)?
>3) The spec talks about "leading edge" in a few places and it's not clear what this means.
>4) "scroll-snap-axis-x/y" seems like a poor name for something that computes to a length value.
>5) "scroll-snap-coordinate-x/y" seems like a poor name for what it is.
>
>6) "scroll-snap-coordinate-x/y" refers to an element's box without saying which box.
>7) "scroll-snap-coordinate-x/y" has an initial value of 0px which means that by default every element's box creates a snapping position. This makes the "elements" feature unusable!
>8) Having to specify scroll-snap-position-x/y:elements to snap to elements is unnecessary. If we have to have scroll-snap-position at all, it's no problem to allow snapping to both elements and a list of lengths at the same time (taking the union).
>
>9) What's wrong with the proposal in https://wiki.mozilla.org/Gecko:CSSScrollSnapping? It's simpler to use and actually works.
>
>10) https://wiki.mozilla.org/Gecko:CSSScrollSnapping tries to address a lot of spec issues that are under-defined in the css-snappoints draft --- for example, how snapping should behave when snapping to the edges of an element which is subject to a CSS transform, and how various scrolling mechanisms interact with snapping.
>
>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