[css-grid] Masonry layout in CSS Grid 3 has potential to cause accessibility problems with reading order.

[nattarnoff]

Assuming all authors code their masonry grid in a valid reading order, screen reader user who are non-visual will have no problem with it. But once we introduce visual screen reader users, low vision with no assistance, magnification software users, and users with cognitive problems, the layout begins to cause problems in focus order and reading order.

If we have
<div>
<item>The quick</item>
<item>brown fox</item>
<item>jumped</item>
<item>over</item>
<item>the lazy</item>
<item>dog</item>
</div>

The screen reader user will hear "the quick brown fox jumped over the lazy dog." When we add the CSS and visual layout, the reading order could be realistically be:

Image description: 6 blocks laid out using masonry reads, "The quick brown fox jumped dog over the lazy"

If these have active controls, the focus order would match the visual as well. I think using a simple sentence quickly demonstrates the damage and problems that could happen for users with cognitive issues, zoom users, and the dissonance a sighted screen reader user would encounter. This gets even more amplified if the author improperly uses tabindex set to a positive number.

I'm not clear on a solution. But I am clear that while the masonry may initially be targeted for photos and other visual pages, we have to expect it to be used by others for different things. If the individual items are standalone, like articles in a newspaper, then this isn't an issue, but we need to provide a way to control the focus/reading order to make sure the content doesn't become inaccessible.

[Loirooriol]

The screen reader user will hear "the quick brown fox jumped over the lazy dog." When we add the CSS and visual layout, the reading order could be realistically be

But speech order not matching visual order is already happening in Grid level 1. Can you clarify what's different with masonry?

If these have active controls, the focus order would match the visual as well.

Would it? From https://drafts.csswg.org/css-grid-1/#source-independence

Note: The reordering capabilities of grid layout intentionally affect only the visual rendering, leaving speech order and navigation based on the source order. This allows authors to manipulate the visual presentation while leaving the source order intact and optimized for non-CSS UAs and for linear models such as speech and sequential navigation.

[rachelandrew]

But speech order not matching visual order is already happening in Grid level 1. Can you clarify what's different with masonry?

at the moment in Grid, yes you can move things out of order, however (other than dense packing) auto-placement doesn't do that. So where you have moved things out of order you should know you have done it. The fact that people are building grid tools that move things out of order and don't warn the user is a different though related subject.

With masonry we give people a really compelling layout method which is likely to cause this problem without the author actively doing it. It also might be tricky to test as at one breakpoint the reordering might not be too bad, and at another awful.

This was brought up at the CSSWG face to face where masonry was first proposed. It does feel that we are adding more layout methods that create this reordering issue without trying to solve the issue in a way that would help this, but also other reordering problems.

[rachelandrew]

See also : https://rachelandrew.co.uk/archives/2019/06/04/grid-content-re-ordering-and-accessibility/ (predates this masonry spec).

[nattarnoff]

If you look again at my first sentence, you'll see my concern is not how a screen reader will relay the information.

Assuming all authors code their masonry grid in a valid reading order, screen reader user who are non-visual will have no problem with it

I think @rachelandrew nailed my biggest concern. As the layout adjusts to content, viewport, or any other factor, the visual reading flow as well as the tab order are going to create problems for other sets of disabled users.

• Neuro-divergent (cognitive) may get lost on where to focus their attention next
• Low vision, no AT may lose where their focus indicator has moved to, or may need to read content from a block that isn't proximate to where they are looking
• Low vision, screen reader will be hearing one thing while trying to locate it on the page because it doesn't follow the visual flow of the page
• Keyboard only - expect a linear flow of tabstops. If the tabstops follow code order, not visual order, they may get lost trying to track things

Using positive tabindex seems tempting here, but if item two goes from being on the right of item 1 to below it, while item 3 slides into where 2 was (these are pure hypothetical) the tab order now may make no sense. So we don't want to force that with HTML code or create a similar thing for reading order.

We need a method though that will ensure that users will be able to read things in their proper comprehension order and that tab order matches visual order. A thought here could be "item priority" which defaults to code order (or no priority), while other options allow you to specify any number of blocks to accept a value that then makes sure the tab order changes to match the visual.

[MatsPalmgren]

I slightly disagree with the premise of this issue. You really shouldn't use (default) masonry layout in the first place if the item placement matters to the semantic meaning of the content. So I think the original example doesn't make sense, for anyone, sighted or not. (There is however masonry-auto-flow: next that could be used for content where the item order matters, but then you sacrifice optimal packing.)

I agree with the later points though, that taking input both visually and from a screen reader simultaneously could be slightly disorienting since the order may not completely match (they are typically somewhat close for default masonry layout though). This is a general problem with Grid and other layout that can place boxes in arbitrary positions.

I don't think adding more HTML/CSS features and relying on authors to use those features is a tenable solution. For two major reasons: 1, authors rarely take the time to do that extra work, and 2, predicting the visual layout is very hard in responsive designs. Instead, I think it should be solved by browser implementations and AT. For example, a browser could provide the visual box order of a Grid container (masonry or regular) to an AT. This could be used by the AT to offer DOM order or visual order as an option to the user. Visual order might be preferred by users that consume both visual and screen reader information simultaneously.

Browsers need to have a concept of visual order anyway to implement selection in a way that makes sense. For example, selecting text with the mouse from an item in the top-left corner of a grid into its neighboring item on the right should really just select the text in those two items, not the entire DOM range in-between. (We don't implement that in Firefox yet, but we intend to.)

[frivoal]

As far as keyboard navigation is concerned, https://drafts.csswg.org/css-nav-1/ is an attempt to cope with the fact that there is no perfect answer to ordering of content laid out in a 2D space, and therefore navigation should itself be available in 2D.

[nattarnoff]

I want to remind folks that there are people who are disabled yet use no AT, so we need to consider that when writing specifications. Like previously said, we have non-visual screen reader users, visual screen reader users, and ZoomText (and similar magnifiers) users. But we also have neuro-divergent users who may use no AT. We have low-vision users whose "AT" is just reducing the screen or viewport's resolution or increasing font size. And there are people who are keyboard only who actually may have no disability or a physical one which doesn't require AT. There seems to be a glossing over some of these types when trying to address the concern I raised.

You really shouldn't use (default) masonry layout in the first place if the item placement matters to the semantic meaning of the content.

Completely agree, but we have to know authors will use it inappropriately unless something is enacted to prevent or work around these issues. Leaving it to authors will bring interfaces that have a11y problems.

I don't think adding more HTML/CSS features and relying on authors to use those features is a tenable solution.

I can agree with this. I'm looking for solutions that don't really leave the potential problems in the hands of authors anyway. I want them to be able to use these grid features without accidentally making an inaccessible experience just because they misunderstood which property to use when. This happens enough with the HTML we have.

As far as keyboard navigation is concerned, https://drafts.csswg.org/css-nav-1/ is an attempt to cope with the fact that there is no perfect answer to ordering of content laid out in a 2D space, and therefore navigation should itself be available in 2D.

I took some more time reviewing that today as it didn't really sink in yesterday. I do think this can answer the problem, however we are relying on the following:

• People accepting a new navigation paradigm. This will take time to be natural
• If the navigation shortcuts are more than just a single key press, we may be introducing a new problem for people with physical disabilities (this is really a comment for that spec)

I think CSS-Grid in general (and especially for masonry) needs to have a dependency on CSS-Nav where when grid is implemented, the parent grid is the spatial navigation container and default spatial navigation properties are implemented on the objects inside. This could prevent all my concerns, but I realize CSS-Grid is in the wild now and adding a dependency to it could have significant unexpected impacts to those sites using grid. WCAG could add a best practice around this, but now we are depending on authors to do the work to know the the two specs and make sure they follow the guidelines for accessibility. I'm aiming for as close to preventing inaccessible experiences by default as possible.

[aardrian]

Playing catch-up…

@nattarnoff

But I am clear that while the masonry may initially be targeted for photos and other visual pages, we have to expect it to be used by others for different things.

I have seen it used for cards, making the entire box an interactive thing.

@rachelandrew

With masonry we give people a really compelling layout method which is likely to cause this problem without the author actively doing it. It also might be tricky to test as at one breakpoint the reordering might not be too bad, and at another awful.

This is a huge point — the few cases I have seen involve devs testing at up to 3 arbitrary breakpoints (iPhone, iPad, their own desktop).

@MatsPalmgren

I slightly disagree with the premise of this issue. You really shouldn't use (default) masonry layout in the first place if the item placement matters to the semantic meaning of the content.

But people will. We have lots of evidence telling us devs will use whatever achieves their visual layout objective regardless of intent (<i> for icon fonts, display: contents as a CSS reset, …).

@frivoal

As far as keyboard navigation is concerned, https://drafts.csswg.org/css-nav-1/ is an attempt to cope with the fact that there is no perfect answer to ordering of content laid out in a 2D

That draft does not address the challenge today and should not be considered a fix. If it happens, that could be ace since it could address years of issues with floats, absolute position, order, auto-placement, tabled layouts… Stuff that pre-dates this by at least a decade.

@nattarnoff

I want to remind folks that there are people who are disabled yet use no AT, so we need to consider that when writing specifications.

Big +1.

I also agree that throwing more features at this will not solve it.

Here's what we can posit based on experience:

• developers will implement it without completely understanding the specification;
• developers will not test with AT nor users;
• developers will test with limited breakpoints;

Perhaps a place to address this is their tooling.

I know many developers rely on the grid (or shape-outside) features in browser developer tools to help them build layouts.

What do you think about browser developer tools warning devs when their layouts break some basic flow patterns? The simplest approach (IMO) is to draw arrows from box to box, and (for LTR languages) use that visualization to highlight problems when the arrow goes both upward and to the left.

I have images demonstrating these arrows where I first proposed the reading / source order tool:
https://adrianroselli.com/2017/11/feature-request-for-firefox-grid-inspector-source-order.html#Update01

Chromium now has a reading order viewer built in, but it does not use arrows to make breaks in the flow more obvious.

This feature would need to built by the browser as it builds support for masonry to be most effective.

[nattarnoff]

I'm all for tools that help developers build more accessible sites. Your concept is interesting, but I'm not sure it well it will delivery the message.

I think the best thing would be to make sure that we include clear examples and demos of how to do it right along with warnings on the impacts of doing it wrong. With clear instructions, then people working on tools and browsers can build ways to clearly demonstrate this and hopefully we can educate devs.

[aardrian]

@nattarnoff

I think the best thing would be to make sure that we include clear examples and demos of how to do it right along with warnings on the impacts of doing it wrong.

Agreed. I was not clear that my suggestion was in addition to this. Partly based on experience with devs today where they do not read the spec or even MDN (so they cannot get the message), they just read an article at popular dev site. I feel the accessibility challenges need to be raised in more than one place.

Which makes my suggestion outside the scope of the CSSWG, I know.

[QINGCHARLES]

How is this issue solved already by big players in the masonry space, e.g. Pinterest?

[tabatkins]

I think this issue can be closed. Masonry presents no new problems that aren't already present with Grid's arbitrary reordering capability, so any solutions that we come up with for either will fix both. And we have indeed come up with such a solution, via reading-order-items.

Tho also, reading-order-items won't even be necessary by default - if you're just auto-flowing things in a Masonry, you'll get an approximation to the standard reading order anyway, and that's exactly what the property would do. reading-order-items will just fix cases where you're either using order to change up the layout order, or explicitly placing some items in tracks.

(Note that the example in the OP showing a confusing order won't happen by default; it requires "over" to have been explicitly placed there, and possibly "the lazy" too. The default placement will instead make the last row [over][dog][the lazy], and since [dog] is somewhat lower than the other two, it's reasonable for the eyes to scan it after [over] and [the lazy] and get the expected reading order.)

[fantasai]

Tab and I drafted a new accessibility and reordering section to address some of the considerations here:
https://drafts.csswg.org/css-grid-3/#order-accessibility

Let us know if you have any suggestions for improvement!

[aardrian]

I appreciate the addition of that section. I think it helps show the risk, especially since as written (including the example) it essentially identifies a probable WCAG SC 1.3.2 : Meaningful Sequence failure. I say probable because an author may only use masonry for a simple picture gallery versus content where the order matters (though that is not my experience so far, as noted above).

[rachelandrew]

@fantasai As the reading-flow values are layout specific, if going with the grid syntax we could reuse the grid-* values. If grid-independent we'll want masonry-* keywords I think.

[Greedquest]

I wrote an algorithm that would get this right in your example in the original post.

Incidentally I think with the current behaviour of placing on the shortest column you would get

The quick	brown fox	jumped
Over	dog	the lazy

However I have an algorithm that generally does a much better job of this and would get the one you posted correct. Balancing visual flow with equal column sizes. Nothing will be perfect though if the grid elements are vastly different sizes.

[rachelandrew]

I've been noodling on the interactions between masonry and reading-flow and I don't think it changes the outcome which masonry option we go with, I also don't think any of this raises fundamental issues that might block the integration work with the HTML spec, but folks can chime in if they think I'm wrong.

The TL:DR is that I think we need to answer two main questions.

• Do we think reading-flow in masonry is more like flexbox or more like grid? The answer to that dictates the number of keywords and the behavior they cause.
• What threshold indicates an item is in the same row or column for reading flow purposes?

Is masonry like grid or flex for reading flow?

For the first part, I think the question to answer is whether we want to take the *-reverse keywords into account or not. Which is really about whether we think masonry is more like grid or more like flexbox where reading-flow is concerned.

For flex layouts we have two keywords for reading-flow: flex-visual and flex-flow. The flex-visual value follows the visual reading flow of items taking writing-mode into account. The flex-flow value follows the flex-direction.

Examples (use Chrome Canary with Experimental web platform features flag on):

• reading-flow: flex-flow, with order modification, flex-direction: row-reverse
• reading-flow: flex-visual, with order modification, flex-direction: row-reverse

For grid layout we assume people intend the reading-flow to be by row or by column, rather than following the ‘flow’.

Examples (use Chrome Canary with Experimental web platform features flag on):

• reading-flow: grid-rows, with placed items
• reading-flow: grid-rows, with grid-auto-flow: dense

Grid-independent masonry option

With a separate masonry spec, if we think masonry behaves more like grid, then we have two new keywords:

reading-flow: masonry-rows
Only takes effect on masonry containers. Follows the visual order of masonry items by row, taking the writing mode into account.
reading-flow: masonry-columns
Only takes effect on masonry containers. Follows the visual order of masonry items by column, taking the writing mode into account.

My second question deals with what exactly a row is, visually. For now assume we’ve figured that out.

If we think masonry is more like flex, then we need an additional keyword.

reading-flow: masonry-flow
Only takes effect on masonry containers. Follows the visual reading order of masonry items, taking the writing mode and masonry-direction into account. This would mean that reading-flow could follow the reversed rows order, I am not sure how useful this actually is.

Note: We could add this additional keyword at a later date if we discovered a use for it.

Grid-integrated masonry option

If we think masonry is more like grid: We avoid having new keywords, therefore reading-flow: grid-rows would attempt to follow the reading-flow by row and reading-flow: grid-column by column, regardless of the masonry grid axis. It would also ignore row-reverse, column-reverse, and wrap-reverse options. Therefore, the following two layouts would be the same in terms of the reading-flow, it would be by row running left-to-right, assuming we’re in English.

.grid {
  display: grid;
  grid-auto-flow: row-reverse;
  reading-flow: grid-rows;
}

.grid {
  display: grid;
  grid-auto-flow: row;
  reading-flow: grid-rows;
}

If we think masonry is more like flex, we could keep the existing keywords, or rename them for consistency to masonry-columns and masonry-rows. However they would remain analogous to the grid-* versions. We would however need an additional keyword.

reading-flow: masonry-visual
Only takes effect on grid containers with masonry in one axis. Follows the visual reading order of masonry items, taking the grid-auto-flow and writing-mode into account.

I find the interaction with grid-auto-flow in the grid-integrated version of masonry to be very confusing. This might be less confusing if the note in Issue 3 of the CSS-GRID-3 spec is followed, and masonry behaves more like flex in general.

What actually is a row?

The reading-flow property attempts to follow logical rows or columns. In masonry it’s possible to have items that poke up into the row above only by a very small amount. Visually, something poking into the row above or column to the left by a few pixels wouldn’t seem like it was in that row or column.

For example, in the WebKit museum demo (needs Safari Technology Preview or see the following screenshot), should we be tabbing from “Flowers in a Vase” to “Painted Chest”, to “Niagara” (deemed both in row 1) then to “Army Boots”. Or do we treat “Niagara” as row 2 and therefore tab “Flowers in a Vase”, “Painted Chest”, “Army Boots”, and then “Niagara”?

We’ll need to figure out that threshold somehow.

[Loirooriol]

What actually is a row?

Why not just follow what https://drafts.csswg.org/css-grid-3/#masonry-layout-algorithm does for indefinite positions?

So “Flowers in a Vase”, “Painted Chest”, “Army Boots”, “Niagara”, “Portrait of a Man” assuming a small masonry-slack.
But it could be “Flowers in a Vase”, “Painted Chest”, “Army Boots”, “Portrait of a Man”, “Niagara” if it's big enough.

[rachelandrew]

I'm not sure if that would give the expected result visually, when tabbing through, but that's partly because I don't actually know what a reasonable threshold is for that expectation.

Also, does it work to tie masonry-slack to reading-flow? People may then use it to try to change how things layout. That might be fine though.

[Greedquest]

So in the algorithm I wrote, a row is defined by looking at the top of each grid item bounding box, and seeing which box in neighbouring columns has the closest top. These boxes are chained together into rows based on their tops having similar y coordinates. I think from my English top left -> bottom right reading view of the world, this visually makes sense.

It ends up creating "rows" that look a little bit like the layers in sedimentary rock:

https://www.researchgate.net/profile/Cheryl-Moss/publication/228494551/figure/fig6/AS:669518733013004@1536637113584/Geologic-cross-section-along-the-northern-edge-of-the-site-Each-of-the-strata-found-at.png

[css-meeting-bot]

The CSS Working Group just discussed [css-grid] Masonry layout in CSS Grid 3 has potential to cause accessibility problems with reading order., and agreed to the following:

• RESOLVED Masonry reading order operates more like grid than flex
• RESOLVED: Masonry reading order operates more like grid than flex

The full IRC log of that discussion

<kbabbitt> rachelandrew: this is an issue raised before we started talking about reading-flow
<kbabbitt> ... in ~2020
<kbabbitt> ... this is something we intend to solve with reading-flow
<kbabbitt> ... really the issue is around what the default behavior is for masonry with regard to reading flow
<kbabbitt> ... bunch of discussion in the issue
<kbabbitt> ... we discussed in other issues that we probably wnat some default reading-flow behavior in masory
<kbabbitt> ... what should that be?
<kbabbitt> ... keyword values probably are tied to how we decide to do masonry
<kbabbitt> ... whether it's part of grid or not
<kbabbitt> ... discussion is, do we want that default behavior
<kbabbitt> ... so that we use reading-flow and follow the visual by default
<kbabbitt> .. I think that's how this is solved
<kbabbitt> ... issue itself predates all that discussion
<kbabbitt> astearns: have questions about what visual order for masonry would be
<bkardell> I wish we could go back and make the visual order work in grid by default
<kbabbitt> rachelandrew: in my comment, my point was we broke it donw
<TabAtkins> Looking in the latest comments of the issue, I do think masonry is much more grid-like in this aspect than flex-like
<bkardell> s/donw/down
<rachelandrew> https://github.com//issues/5675#issuecomment-2565155995
<kbabbitt> rachelandrew: issue there is whether we think masonry is more like grid or more like flexbox
<kbabbitt> ... opposite model in reading-flow
<kbabbitt> TabAtkins: I believe masonry should be thought of more like grid than flexbox
<kbabbitt> ... flexbox going in reverse direction can be because you're laying out buttons on other side
<kbabbitt> ... i.e. outward to inward
<kbabbitt> ... doesn't apply in masonry
<kbabbitt> .
<kbabbitt> .. going to read in visual order regardleses of how we flow it
<kbabbitt> rachelandrew: makes sense
<kbabbitt> astearns: the idea of using item tolerance as a measure for which row to assume an item is in makes some sense
<kbabbitt> TabAtkins: we can almost just use the source order except for explicitly placed items
<kbabbitt> ... have to reinterpret that if we're doing visual flow
<kbabbitt> ... having to use item-tolerance in the same way as ? is correct way to go
<kbabbitt> ... if you explicitly place first item in column 4, then auto flow a bunnch of items
<kbabbitt> ... pure source order will read item in column 4 first then others
<kbabbitt> ... but that's roughly visual order anyway
<kbabbitt> ... visual order would want to reinterpret things
<kbabbitt> ... so item in column 4 is read 4th
<kbabbitt> ... use item tolerance to tell when something is next or following row
<kbabbitt> fantasai: if that 4th item is your righ thand sidebar read that first?
<kbabbitt> ... which makes me wonder if we should have a mode that allows reordering of auto placed items
<kbabbitt> ... but leaves explicitly placed items where they are
<kbabbitt> TabAtkins: if you use order property alongside you get that
<kbabbitt> fantasai: for some of these cases
<fantasai> scribe+
<fantasai> TabAtkins: My proposal is that masonry, whether we do this by grid values or making new masonry values, but use something like grid-modified order
<fantasai> TabAtkins: and one that's visual, which is auto-flow taken into account
<fantasai> TabAtkins: If you have things you've explicitly placed but should be read first, order-modified grid order works
<rachelandrew> q+
<fantasai> TabAtkins: For auto-placed items, natural masonry flow already gives a reasonable analog to desired reading order
<fantasai> fantasai: It depends on your spanning stuff
<fantasai> TabAtkins: when using explicit placement for layout reasons, e.g. sidebar and main area
<fantasai> TabAtkins: the 'visual' value would read them left to right, using item-tolerance to decide when something is in the next "row" or whateer
<astearns> ack rachelandrew
<kbabbitt> fantasai: I can never keep track of reading-flow values
<kbabbitt> rachelandrew: not convinced that source order value will always be ok
<kbabbitt> ... examples I've seen have inserted a very large item
<kbabbitt> .. which is likely to cause weird jumping around
<kbabbitt> ... even if source order is roughly correct
<kbabbitt> ... granted this is on experimental masonry
<kbabbitt> ... maybe in practice this isn't such a problem
<kbabbitt> ... but reasonably large items could force things into strange layout
<kbabbitt> ...that's what the OP of this issue had in mind
<kbabbitt> ... the idea that you could have slightly odd ordering because of a large item
<kbabbitt> TabAtkins: OP has very first etxample of a masonry not laid out in masonry order
<kbabbitt> astearns: it's an example of some reordering htat masonry can do
<kbabbitt> rachelandrew: don't know what order they were using
<kbabbitt> fantasai: there have been suggestions to be able to have named tracks
<kbabbitt> ... e.g. every other track has a name
<kbabbitt> .. use auto placement in combination with a namer
<kbabbitt> ... we have talked about for grid and masonry where you can say I want to auto place but only in B-style tracks
<kbabbitt> ... could result in a layout like this
<kbabbitt> rachelandrew: would be good to account for that kind of thing
<kbabbitt> ... e.g. I can see how just having large size items could cause jumping about with just source order
<kbabbitt> TabAtkins: would like to see an example with large item in correct masonry layout to see effects
<kbabbitt> ... if you're setting things inmaronry to explicit column sthings can get wawy off
<kbabbitt> ... but that's something you're doing explicitly
<kbabbitt> ... don't do that. or do with order to compensate
<fantasai> https://www.w3.org/TR/css-grid-3/#order-accessibility
<astearns> q+
<kbabbitt> ... in starndard case of masonry with reasonable tolerance and explicit placement which is not smeantically important
<kbabbitt> ... then order from masonry layout gives you the best you can automatically doi
<kbabbitt> ... or any other algo will be similarly abitrarily wrong sometimes
<kbabbitt> astearns: disagree with one point re; source order
<kbabbitt> ... even if not explicitly placing anything
<kbabbitt> ... if what you put into masonry has a large amount of variation in size
<kbabbitt> ... visual order is going to be completely different from source order
<kbabbitt> TabAtkins: comic book panel style with wacky arrangement of panel sizes, still read in order
<kbabbitt> astearns: I heard source order for reading order would be a reasonable thing for masonry generally?
<kbabbitt> TabAtkins: no
<astearns> ack astearns
<kbabbitt> ... we have grid rows and grid columns as values right now
<kbabbitt> ... either we adopt the grid values interpreting grid rows and grid columns as masonry visual
<kbabbitt> ... or we adopt two new masonry keywords, masonry order and masonry visual, that do the two things
<kbabbitt> astearns: we can resolve masonry order is much more like grid order?
<kbabbitt> rachelandrew: yes, do finer details once masonry is fully decided
<kbabbitt> fantasai: agree with resolution not sure it solves issue
<kbabbitt> astearns: it doesn't but it gives you things to throw out at least
<kbabbitt> astearns: Proposed 1: Masonry reading order operates more like grid than flex
<kbabbitt> RESOLVED Masonry reading order operates more like grid than flex
<kbabbitt> RESOLVED: Masonry reading order operates more like grid than flex
<kbabbitt> astearns: could decide on reusing grid values or making new masonry values
<kbabbitt> ... or could leave it
<kbabbitt> rachelandrew: once we have a decision on how masonry is turned on, that makes it more clear
<kbabbitt> ... in terms of names, better to make sure they work well together