- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Thu, 30 Jan 2014 12:24:01 +1300
- To: www-style <www-style@w3.org>
- Cc: Matt Rakow <marakow@microsoft.com>
- Message-ID: <CAOp6jLaWcstcfKThP7o7JV-BU8CC0tcO1tcCjH-rMXEdGyabnQ@mail.gmail.com>
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
Received on Wednesday, 29 January 2014 23:24:30 UTC