Masonry and reading order

I recently wrote a post about the CSS masonry proposal on the Chrome for Developers blog. I was keen not to muddy the waters with anything that wasn’t the main point of that postβ€”which was to explain why the Chrome team felt that masonry should be specified outside of grid. Since then, a couple of people have mentioned the content reordering issue that masonry presents, notably Andy Bell in his post I’m worried about the tabbing behaviour, rather than the syntax and name of CSS masonry. This is just a quick note to hopefully share some positive news on that front.

CSS masonry is an example of an automatic layout method, where the developer of the site doesn’t have control over where the items end up, and their placement can change due to size of content, or available space in the component. The other place where this can happen is if you use the dense packing mode in grid, with grid-auto-flow: dense. There’s a proposal however that aims to deal with this, that would let developers indicate to the browser that they want to follow the “visual” flow of items rather than source order. This is currently named reading-order-items, and I recently added a draft of the proposal to the CSS Display Level 4 editor’s draft. The specification deals with reordering both in an automatic sense, but also the reordering you might want to do when placing items on the grid.

That draft only mentions grid and flexbox because we are purposefully scoping this to specific layout methods where reordering is likely to occur. At the moment there is no separate masonry specification. If we end up with CSS Masonry Level 1, rather than bundling masonry with grid, then we can expand reading-order-items as well. Ideally we could then implement masonry at the same time as the method to deal with the reading order issue it creates.

To be clear, my personal hope is that we can land the proposal for reading-order-items before we have interoperable masonry, in whatever form it takes. This is not a new hope. In fact, at the CSS Working Group meeting in January 2020 where the Mozilla proposal for masonry was first demonstrated, Brian Kardell and I brought up the content reordering issue, and then spent some time discussing possible solutions. I’ve been talking about this issue even before masonry-in-grid started to be discussed, for example in this 2019 post on this blog. Members of the community have also raised concerns, there some discussion specifically related to masonry in this issue.

I’m really excited about the fact that we have some forward motion on a reading order solution. I presented the idea at TPAC last year, with the accessibility folks in the room, and they were in agreement that this seemed like a workable way forward (obviously pending testing once we have an experimental implementation). There’s an engineer at Chrome working on a prototype, and I’m keeping on top of questions so we can bring any issues to the CSSWG. I’ll also talk about the proposal at CSS Day in a couple of weeks. We are a way off this being something you can rely on to solve this problem, but do keep an eye out for an implementation in Chrome Canary, as I’d love to get as many people as possible testing this and looking for edge cases once it’s there. In the meantime, I’ll do whatever I can do to keep prodding it along the path to solving this issue for us all.


Christian "Schepp" Schaefer May 26, 2024 Reply

@rachelandrew I’d love to hear and discuss reading order in more depth at the in-person CSS CafΓ© the day after the conference. So if you hadn’t had enough CSSy discussions during the conf and if it doesn’t interfere with any plans on running, please feel invited to drop by:

CSS CafΓ© meets CSS Day: an in-Person Pop-Up Event!, Sat, Jun 8, 2024, 10:30 AM | Meetup

Rachel Andrew May 26, 2024 Reply

@Schepp I’m hoping to pop along πŸ™‚

Leave a Reply