Bug 145099

Summary: [css-scroll-snap] Support masonry layouts and more advanced snappoint selection
Product: WebKit Reporter: Brent Fulgham <bfulgham>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: bfulgham, mrobinson, sam, simon.fraser, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
See Also: https://bugs.webkit.org/show_bug.cgi?id=142523
Bug Depends on: 219345, 220765, 220915, 221030, 227949    
Bug Blocks: 218115    
Attachments:
Description Flags
Example Masonry Grid
none
Simple masonry example using overflow div none

Brent Fulgham
Reported 2015-05-16 15:58:17 PDT
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.
Attachments
Example Masonry Grid (10.71 KB, application/pdf)
2015-06-15 22:12 PDT, Brent Fulgham 		no flags
Details
Simple masonry example using overflow div (2.42 KB, text/html)
2015-06-16 14:22 PDT, Wenson Hsieh 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2015-05-16 15:58:54 PDT
<rdar://problem/20989900>
Sam Weinig
Comment 2 2015-05-17 12:06:17 PDT
(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
Comment 3 2015-05-18 21:03:21 PDT
(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
Comment 4 2015-05-18 21:04:36 PDT
(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
Comment 5 2015-05-19 09:06:38 PDT
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
Comment 6 2015-05-19 09:27:01 PDT
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
Comment 7 2015-06-15 22:12:23 PDT
Created attachment 254933 [details] Example Masonry Grid
Wenson Hsieh
Comment 8 2015-06-16 14:22:15 PDT
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
Comment 9 2021-07-07 07:17:02 PDT
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
Comment 10 2021-07-07 07:18:13 PDT
*** Bug 145157 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.