So you're saying the a11y tree and tab ordering is bypassing the actual ordering of content and instead traversing the columns one by one? I'd call that a bug. In a masonry layout the expectation of a sighted user is that there is no continuity from column to column, but instead through the visual line. And the "unexpected" (disagree) ordering you show does that. I think the issue would be that tab ordering is ignoring the raw ordering of the content and instead trying to emulate something visual, almost certainly some kind of hold over of the implementation as it currently exists.

Maybe it's just me, but as a sighted user I have no idea how to read this kind of layout. My expectation would be that any sane designer wouldn't use this kind of layout in the first place.

What's the "visual line" in the first example? It goes 1, 2, 3, 4; then down to 5; then a sudden break in the line as it jumps over 3 to the left to reach 6?

Are we supposed to mentally sort the boxes by the top edge coordinates before reading? That would almost make sense of the second example, except that it doesn't explain why 9 comes before 10. Maybe sort by the coordinates of the bottom edge instead? But then 5 should be first. How do I read this thing?

Edit: Actually box 9 seems to start 1 pixel above box 10, so sorting by top edge does work! So a sighted reader simply has to zoom in to the pixel level and carefully measure the coordinates of all the boxes to find the reading order.

My experience with it has mostly been on Flickr, and I hated it for this exact reason, even though that was mostly pictures not text. Sure, it's very pretty if you just want to look at the site and not engage with it in any detailed way, like professional designers seem to intend for us, but I always wanted to look at a page of pictures and scan my attention over them systemically, finding those that interested me, being distracted by them briefly, then returning to the scan and knowing where I'd left off.

Trying to do this with the "masonry" was horrible. What direction do you go in? Horizontally? Then how do you track which elements belong in which row, where you've already been? They're all interleaved. Vertically? Have fun scrolling down and down and down forever as the page loads more and more content dynamically. No, neither of those is how you're meant to engage, you're supposed to simply sit quietly and look at the big wall of pretty pictures.

Giving designers a non-javascripty way to do it is nice, I guess, but I really hope the effect is that the bad layouts we already have are at least better executed technologically, rather than that the better technology encourages designers to use bad layouts more often.

Well no, the idea is that these are not related pieces of content. It's less of a newspaper article and more about independent items that are placed across the page. You don't have to follow the flow exactly as a user, but following the visual line is "more correct" than following through all of column A, then column B, etc.

Well, the idea with this layout is that there isn't really an inherit order to the children. You would use it where it doesn't matter which order you 'read' the items.

If the order was important, you would use a 1D or 2D layout.

The problem here is that users will look at the end result and see a series of columns, but that the use of masonry makes it not that at all.

I’m saying that masonry is risky if you’re using it purely visually, specifically because it’s purely visual. It’s the same deal with the CSS `order` property: it can be useful, but you have to be careful not to break expectations.

CSS is almost purely visual. There are a few cases where it influences the accessibility tree (e.g. `display: none`, `speak-as`, `appearance` in some user agents), but never in anything like order.

If you make it look like columns instead of make it look like a wall of independent blocks, then yes.

Focusing solely on sighted users, I think the current ordering makes sense. What you propose would require often scrolling up and down to view the items in order, and would have large layout shifts if more items are added.

Why not just use widely supported CSS Multi-Column Layout for masonry effect?

That's just a random demo. It's not particularly relevant for the concept they're trying to gather feedback on

The demos should be motivating the feature. A bad demo is destructive to that effort. This is a very bad demo.

If you open the demos in a browser like Safari that doesn't support the feature, the demos remain as normal grid-aligned cells.

There I realize that masonry mainly works when your cells have such different heights that to grid-align them creates a lot of vertical dead space. Images and news blocks with images make sense for masonry for this reason and it feels good.

But text-only cells where the cell heights don't differ much, they seem better without masonry. The megamenu demo also works much better as a normal grid because they start with a header so grid alignment lets you scan the headers left to right easily.

A text-only newspaper could make sense with masonry because you aren't trying to navigate relationships between the items, and presumably the content can vary the cell height a lot.