Item Flow – Part 2: next steps for Masonry

I’ll prefix that I don’t know if a design pattern like masonry needs quite this much attention — I’ve always had it in my mind as a very specific answer to a very specific question: “how do we lay out various sized media?”

Masonry is really useful for sites like Unsplash and Pinterest — galleries — but I’m not sure how useful it is away from that.

But, it’s great to see browser vendors trying to remove the need for JavaScript — often the tool of choice for a masonry layout — and bring that system to where it belongs: CSS.

I’ve read both WebKit’s first post about item-flow (which we also covered) and also, Chrome’s display: masonry approach. I think based on what WebKit have expanded on with this latest post, vs. the narrower lens of Chrome’s solution puts item-flow in the lead for me.

The reason? I think item-flow presents more flexibility. WebKit are for sure, framing it as a way of achieving masonry buts that’s also the key: a way. The item-flow approach brings wider improvements to both flexbox and grid.

Chrome’s proposal — albeit very nicely done and seems like it’ll be easy to author — feels a little too specific. They’re solving masonry only with their approach.

An iteration that expands on the already excellent layout options we have available to us in CSS makes the most sense as I see it. I also see more of a possibility that people can get creative with their layouts — both grid and flexbox — with item-flow. It’s hard for working group members to see that creativity, but my advice to them would be give people the flexibility and watch the magic happen.

I know the CSS working group have already met to discuss these proposals, but no firm decisions have been made yet, either way. Browser vendors really benefit from opinions from people that actually build websites, so you should post about new CSS features too! It’s certainly something I need to get better at.

All I ask is that tabbing behaviour is worked out.

Check it out Advert