The existing two-axis scroll snap implementation works fine for a regular 2-dimensional grid, but fails if we want to support irregularly-shaped containers of elements (e.g., "Masonry-style layout"). To better accommodate this type of layout, we need to switch from disparate vectors of x and y snap points, and instead consider snap points as 2-dimensional entities. The downside of this approach is that very large grids would consume much more memory (i.e, we go from 2N memory use to N^2). However, I doubt that we will encounter scroll snap documents of sufficient size for this to be a problem.
<rdar://problem/20989900>
(In reply to comment #0) > The downside of this approach is that very large grids would consume much > more memory (i.e, we go from 2N memory use to N^2). However, I doubt that we > will encounter scroll snap documents of sufficient size for this to be a > problem. Scary statement! What does the N used above represent?
(In reply to comment #2) > (In reply to comment #0) > > The downside of this approach is that very large grids would consume much > > more memory (i.e, we go from 2N memory use to N^2). However, I doubt that we > > will encounter scroll snap documents of sufficient size for this to be a > > problem. > > Scary statement! What does the N used above represent? N would be the number of elements contained inside the scroll region. E.g., if we had a grid of photos or something, N would be the number of images.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #0) > > > The downside of this approach is that very large grids would consume much > > > more memory (i.e, we go from 2N memory use to N^2). However, I doubt that we > > > will encounter scroll snap documents of sufficient size for this to be a > > > problem. > > > > Scary statement! What does the N used above represent? > > N would be the number of elements contained inside the scroll region. E.g., > if we had a grid of photos or something, N would be the number of images. Just to be more precise, each 'N' would probably represent a pair of float values representing the "scroll-snap-coordinate" of the element.
Sam dropped by and helped me understand that my proposed data structure change would be at worst N, while our existing implementation is some smaller value proportional to the number of horizontal elements plus the number of vertical elements.
Note: The wording in the CSS Scroll Snap specification <http://dev.w3.org/csswg/css-snappoints/#propdef-scroll-snap-coordinate> indicates that we should support having multiple snap coordinates in a single element. To properly achieve this (without affecting other elements in the container) we will need to implement a data structure like I am proposing here.
Created attachment 254933 [details] Example Masonry Grid
Created attachment 254968 [details] Simple masonry example using overflow div HTML page resembling Brent's picture above. The current implementation computes snap offsets instead of actual points, producing extra snap points.
Renaming this bug to reference handling masonry layouts. There are two pieces to this: * Not selecting snap points when a scroll wouldn't bring its snap area onscreen. * When a bidirectional scroll chooses two incompatible snap points for the x and y axis, choosing the snap point that is the shortest distance away from the original scroll position.
*** Bug 145157 has been marked as a duplicate of this bug. ***