- From: Majid Valipour <majidvp@chromium.org>
- Date: Thu, 21 May 2015 15:38:33 +0000
- To: www-style@w3.org, Matt Rakow <marakow@microsoft.com>
- Message-ID: <CAB8RdXuf2B3gV1mQJST8+khLaqMpZK4RxsdBHpu1uOCfD+j0=g@mail.gmail.com>
Hi, 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%; } <body> <section> </section> <section id='gallery-horizontal'> <img> <img> </section> <section> </section> <body> 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 <https://docs.google.com/document/d/18GGuTRGnafai17PDWjCHHAvFRsCfYUDYsi720sVPkws/> and Scroll Customization <https://docs.google.com/document/d/1VnvAqeWFG9JFZfgG5evBqrLGDZYRE5w6G5jEDORekPY/> APIs. Thanks Majid
Received on Friday, 22 May 2015 11:19:08 UTC