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

CSS Snappoints feedback

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:13 UTC