For my GUI layout library I decided "snaplines" could be a more fundamental concept than grids (because a grid can be defined with horizontal and vertical snapl

For my GUI layout library I decided "snaplines" could be a more fundamental concept than grids (because a grid can be defined with horizontal and vertical snaplines). Essentially it's just a linear constraint like "there exists a variable X_snap1, such that box1.right <= X_snap1 and box2.left >= X_snap1." The key is that if you re-use the same snapline variable for subsequent rows, it aligns a column. Another key idea was that the snaplines are completely independent from the logical (hierarchical, tree) structure of the "document" (aka form). So like if you wanted controls above and below something to be horizontally aligned with each other, but not affect content in the middle, you could do that by just only associating some controls with those snaplines; the fact that the snapline cuts across the middle content need not affect it because it's an abstract "membership" in a group not a physical barrier. How I came to this design was I had done XAML layouts with WPF on Windows, and while I preferred to use the Grid tag to solve most layout problems, I was also frustrated with its limitations: you kind of have to plan ahead, if you discover you need another alignment line you have to renumber things, or maybe you need to fuse certain cells, etc. I realized that I was using the grid to get alignment lines, but didn't (necessarily) want all of the other behaviors which come with it.