Bug 145099 – [css-scroll-snap] Support masonry layouts and more advanced snappoint selection

• Component: Layout and Rendering
• Status: NEW

[Brent Fulgham]

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.

[Radar WebKit Bug Importer]

<rdar://problem/20989900>

[Sam Weinig]

(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?

[Brent Fulgham]

(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.

[Brent Fulgham]

(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.

[Brent Fulgham]

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.

[Brent Fulgham]

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.

[Brent Fulgham]

Created attachment 254933 [details]
Example Masonry Grid

[Wenson Hsieh]

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.

[Martin Robinson]

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.

[Martin Robinson]

*** Bug 145157 has been marked as a duplicate of this bug. ***