Greedy shortest-column, not round-robin
Dealing tiles across columns in order is simpler to write and looks wrong the moment two tall images land in the same column. Putting the next tile wherever the total is currently smallest is the whole idea.
Back
MooPin
Pinterest-style column grid for MooTools
A MooTools plugin that packs tiles of different heights into even columns, the way Pinterest does.
Problem
- Every column-grid plugin in 2014 required jQuery
- Masonry, Isotope, and Wookmark were all jQuery
- MooTools apps had to load a second framework for a layout
- Or position tiles by hand and redo the math on resize
- Round-robin columns look wrong the moment two tall images land together
- Wanted the Pinterest look without pulling in jQuery
Solution
- ~120 lines on MooTools core, nothing else required
- Greedy placement: next tile goes in the shortest column
- Idempotent full re-layout via a single render() call
- One public method, two events, four options
- Infinite scroll is append markup, then render() again
- Static grid and infinite-scroll demos shipped with it
Outcome
- Column packing without a second JavaScript framework
- Bottom edge of the grid comes out roughly level
- Infinite-scroll host code is about six lines
- Verified in Chrome 37+ and Firefox 32+
- MIT licensed for production use
- Filled a real gap in the MooTools plugin landscape
~120
lines of source
1
public method
2
events
4
options
Architecture Review
System design · Pipeline · Decisions
System Architecture
How It Works
- 1
Initialise
new MooPin({ container }) measures the container, counts columns from the first tile width, and keeps a running height per column.
- 2
Layout pass
Each tile is placed in whichever column is currently shortest, then absolutely positioned. That greedy choice is what keeps the bottom edge roughly even.
- 3
Re-entry
onWindowResize re-runs the whole pass. Infinite scroll appends markup and calls render() again — no incremental state to keep in sync.
Key Decisions
Re-run the layout whole, don't track incremental state
The layout pass is idempotent. That is why the infinite-scroll demo is six lines of host code: append the new markup, call render() again. It costs a full re-layout on every trigger, which was fine at demo sizes.
MooTools native, not a jQuery dependency
The sites that needed this were already on MooTools. A native plugin beat asking those teams to pull in jQuery for one layout effect.
Evaluation
There is no test suite; correctness was two browsers and my eyes. Reading it now, the resize handler fires on every resize event with no throttle, three loop variables leak to the global scope, column width is read off the first tile and assumed for the rest, and tiles have to carry explicit image dimensions — measure before decode and every height comes back zero.
What I'd Change
- Throttle the resize handler
- Don't assume the first tile's width
- Observe image load instead of requiring width and height
- Today this would be CSS grid