5 ms·

I strongly dislike the megamenu demo <https://webkit.org/demos/grid3/megamenu/ https://webkit.org/demos/grid3/megamenu/>, and feel masonry is completely inappro

I strongly dislike the megamenu demo <https://webkit.org/demos/grid3/megamenu/ https://webkit.org/demos/grid3/megamenu/>, and feel masonry is completely inappropriate there. It makes a complete mess of flow direction, badly breaking expectations. The reading order you’d expect: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-2.png https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-2..... What the demo actually gives you: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-1.png https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-1..... This affects correct reading order and tab indexes. Basically, sighted users will always read things in the “wrong” order. This just drives home that there is no structure, it’s just an unstructured bag of links. Except… actually if you go through them in numbered order, it looks like there was some fairly logical ordering. It’s just been utterly demolished by inappropriate masonisation. (I’ve turned on “number items” in those screenshots. Normally, it’d look more like normal columns with no backgrounds.) The way it should be implemented is with columns, but adding `break-inside: avoid` on each section, which their demo has missed. The newspaper demo is also a little dubious for similar reasons, but it’s a much smaller deal. Now images and such media which are in more independent blocks and where reading order isn’t such an ingrained thing, masonry layout does work better there. There are still patches where things can be a bit iffy, mostly around tab indexing, but it’s not obviously wrong any more.

niutech 3y ago
Why not just use widely supported CSS Multi-Column Layout for masonry effect?
rezonant 3y ago
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.
- chrismorgan 3y ago
  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.
  - vidarh 3y ago
    If you make it look like columns instead of make it look like a wall of independent blocks, then yes.
- ptx 3y ago
  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.
  - amenhotep 3y ago
    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.
sebstefan 3y ago
That's just a random demo. It's not particularly relevant for the concept they're trying to gather feedback on
- chrismorgan 3y ago
  The demos should be motivating the feature. A bad demo is destructive to that effort. This is a very bad demo.
  - sebstefan 3y ago
    People who have nothing to say on the shed talk about the color
  - hombre_fatal 3y ago
    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.
KTibow 3y ago
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.

niutech 3y ago

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

rezonant 3y ago

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.

chrismorgan 3y ago
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.
- vidarh 3y ago
  If you make it look like columns instead of make it look like a wall of independent blocks, then yes.
ptx 3y ago
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.
- amenhotep 3y ago
  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.

sebstefan 3y ago

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

chrismorgan 3y ago
The demos should be motivating the feature. A bad demo is destructive to that effort. This is a very bad demo.
- sebstefan 3y ago
  People who have nothing to say on the shed talk about the color
- hombre_fatal 3y ago
  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.

KTibow 3y ago

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.