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