W3C home > Mailing lists > Public > www-style@w3.org > May 2015

[css-snappoints] Separate scroll-snap-coordinate into {x,y} offsets

From: Majid Valipour <majidvp@chromium.org>
Date: Thu, 21 May 2015 15:38:33 +0000
Message-ID: <CAB8RdXuf2B3gV1mQJST8+khLaqMpZK4RxsdBHpu1uOCfD+j0=g@mail.gmail.com>
To: www-style@w3.org, Matt Rakow <marakow@microsoft.com>

I was reading the latest snappoints spec draft
<http://dev.w3.org/csswg/css-snappoints/> and noticed that element snap
coordinate is defined as a list of <position> values.

Current definition: scroll-snap-coordinate: none | <position>#
Simple example: scroll-snap-coordinate: 0 0, 10px 10px

The problem I see here is that it forces elements to always contribute snap
points on _both_ axis which may be undesirable and unexpected. This also
feels to be at odds with the rest of the spec which considers snap points
to be defined for each axis independently e.g., scroll-snap-points-{x,y}.

I think the spec should separate the coordinate properties for x and y
i.e., scroll-snap-coordinates-{x,y}. This is more consistent with the rest
of the spec as well.

# Example Scenario
Consider the following example <http://jsbin.com/qureho/4> where the author
intends for
vertically scrolling body to snap to sections and horizontal
image gallery to snap to images. However according to the spec the below
code will result in  body to snap to both the sections and image centers.

body {
   overflow-y: scroll;
   scroll-snap-type: mandatory;
   scroll-snap-destination: 0 0;

section {
    scroll-snap-coordinate: 0 0;

#gallery-horizontal {
    overflow-x: scroll;
    white-space: nowrap;
    scroll-snap-type: mandatory;
    scroll-snap-destination: 50% 50%;

img {
    display: inline-block;
    scroll-snap-coordinate: 50% 50%;

   <section> </section>
   <section id='gallery-horizontal'>
   <section> </section>

To give you some context, I am looking into implementing
<http://crbug.com/311234> snap points for Blink so I expect to be sending
more questions and comments to the list as I make progress with the
implementation. If you are curious, our hope is to build blink's
implementation on top of some new primitives which are being actively
developed such as CompositorWorker
and Scroll Customization

Received on Friday, 22 May 2015 11:19:08 UTC

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