- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Jan 2020 10:12:58 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Masonry Layout`, and agreed to the following: * `RESOLVED: Adopt Masonry layout proposal, editors fantasai and Tab, and Mats if he's convinceable` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Masonry Layout<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/4650<br> <fantasai> jensimmons: Mats Palmgren, layout engineer at Mozilla, over Christmas break, this is what he did for Christmas present<br> <fantasai> jensimmons: He's thought in detail about what it would take to add something to Grid to accomplish Masonry layout<br> <fantasai> jensimmons: It's lots of detailed from implementer perspective<br> <fantasai> jensimmons: So what is Masonry layout?<br> <fantasai> jensimmons: It's a popular idea of how to lay out content on the Web, e.g. on Pintrest<br> <fantasai> jensimmons: People wanted to do it with Grid, but you can't really, still have to use JS<br> <fantasai> jensimmons: works fast on Pintrest because they put a lot of money and effort into it<br> <fantasai> jensimmons: others use this library<br> <fantasai> jensimmons: Here's what the layout looks like [shows outline]<br> <fantasai> jensimmons: Why not do it with flexbox? well that would give the wrong content order<br> <fantasai> jensimmons: Don't want the early things to be below the fold with late things up at top in the later columns<br> <fantasai> jensimmons: also makes a problem with lazy loading, would rejigger layout<br> <fantasai> jensimmons: Order ppl need is going across<br> <fantasai> jensimmons: This version of Masonry, the most common one, is that as it goes to fill in the rest of the pieces of content<br> <fantasai> jensimmons: puts next item into the column that is the shortest, so always closest to the top<br> <fantasai> jensimmons: Other option is to go from 1st column to last column always<br> <fantasai> jensimmons: but skip columns that are too full to keep things roughly in order<br> <fantasai> jensimmons: Mats believes he's figured out how to do it in Grid<br> <fantasai> jensimmons: That's the issue<br> <fantasai> jensimmons: I think it would be popular and ppl would be super happy to have<br> <fantasai> TabAtkins: Yes, this has been requested for like 15 years<br> <fantasai> TabAtkins: Overall, love the proposal, think it's great, lots of detail in it<br> <bkardell_> q+<br> <fantasai> TabAtkins: Only concern, making it part of Grid instead of its own display type<br> <rachelandrew> q+<br> <fantasai> TabAtkins: Think we should make it display: masonry, copy over concepts from Grid<br> <heycam> fantasai: any examples of things you're concerned about?<br> <emilio> q+<br> <heycam> fantasai: this is somewhat similar in that subgrid is also kind of like a mode<br> <heycam> ... which creates a different way of laying out items in the grid<br> <heycam> ... masonry is a different model for doing the rows<br> <fantasai> TabAtkins: Sugrid is fundamenally a grid still<br> <fantasai> TabAtkins: but Masonry is different<br> <fantasai> TabAtkins: Example, Mats suggests an align-tracks property that only applies to masonry<br> <heycam> fantasai: what's it do?<br> <fantasai> TabAtkins: it aligns the Masonry stuff within their track<br> <fantasai> TabAtkins: So there are a few different layout concepts<br> <fantasai> TabAtkins: that don't apply to Masonry in Grid<br> <fantasai> TabAtkins: and that don't apply to Grid in Masonry<br> <jensimmons> q+<br> <fantasai> TabAtkins: So I think we should re-use as many concepts as possible<br> <tantek> Is this orientation specific? I.e. presumably masonry refers to the overlapping brick like layout. Flickr does this for displaying photo results, e.g. https://flickr.com/photos/tags/csswg<br> <fantasai> TabAtkins: but separate out as a distinct display type<br> <fantasai> TabAtkins: that has a clear signal for what applies here vs in Grid<br> <fantasai> florian: For align-tracks property, if we did have different modes, could we use an existing alignment property to do this?<br> <heycam> fantasai: if I understand correctly, you have a box, then some masonry tracks<br> <heycam> ... each individual track aligning its content to the bottom<br> <heycam> ... rather than taking the entire masonry chunk and sliding it to the bottom<br> <heycam> ... isn't this exactly what justify-content does in flexbox? why not just reuse align-content?<br> <heycam> TabAtkins: only given an hour thought to this<br> <heycam> fantasai: I think it's premature to split it out, it's its own layout model, but which should think about that<br> <heycam> ... for now leaving it as part of grid makes sense until we have a clearer idea of what doesn't fit<br> <tantek> q?<br> <fantasai> Rossen__: Fan of this proposal<br> <fantasai> Rossen__: What are we trying to get out of this discussion?<br> <fantasai> heycam: Wanted to get temperature of the room, see if there's interest<br> <fantasai> heycam: and also get thoughts on integration<br> <fantasai> bkardell_: Of course I want this<br> <fantasai> bkardell_: Want to say same thing as Grid and Flexbox, we should stop and solve the a11y problem with content reordering<br> <fantasai> bkardell_: I have concerns about that, that's all<br> <fantasai> rachelandrew: I would really like to see Masonry solved<br> <fantasai> rachelandrew: I also agree we should look at content reordering proble<br> <iank_> q+<br> <fantasai> rachelandrew: Don't think it should be part of Grid<br> <astearns> ack bkardell_<br> <fantasai> rachelandrew: Trying to teach it, it's not a grid<br> <TabAtkins> I think this doesn't introduce any new content-reordering problems; it's definitely no worse than "a pile of floats", still according with the standard "left to right, top to bottom" ordering.<br> <astearns> ack rachelandrew<br> <TabAtkins> (Unless you use 'order', of course.)<br> <fantasai> rachelandrew: would make a lot more sense to have a separate layout model<br> <tantek> Is there no attempt to do baseline alignment across masonry items in different columns?<br> <tantek> That might be one reason to consider it grid-like<br> <Rossen__> ack emilio<br> <fantasai> emilio: I don't know if should be separate model<br> <fantasai> emilio: but multicol changes layout model quite a lot, this still mostly fits within grid layout paradigm<br> <fantasai> emilio: can share a lot of code<br> <fantasai> emilio: so not quite like multicol<br> <Rossen__> ack jensimmons<br> <fantasai> jensimmons: I think these are great issues to bring up<br> <fantasai> jensimmons: taking of introducer hat<br> <fantasai> jensimmons: this is jen<br> <fantasai> jensimmons: I was also concerned about a11y order<br> <astearns> tantek: I doubt it would be feasible to to baseline alignment when there are not grid lines in the block direction<br> <fantasai> jensimmons: but aftter explaining, I think it's less of a problem than Grid<br> <fantasai> jensimmons: It does seem like ppl are tabbing through DOM order, focus rings<br> <fantasai> jensimmons: Easier because content doesn't go below the fold<br> <fantasai> jensimmons: I do feel like this belongs as grid<br> <fantasai> jensimmons: there are 2 axes, and this only works in one axis<br> <fantasai> jensimmons: do this in row directly, have all power of grid in column direction<br> <fantasai> jensimmons: Things when it comes to subgrid and nesting a grid inside a grid, might want things to interact<br> <tantek> would https://flickr.com/photos/tags/csswg be an example of doing it in the "row direction"?<br> <fantasai> jensimmons: things interact<br> <Rossen__> q?<br> <fantasai> jensimmons: Just choose how you want to treat other axis<br> <fantasai> jensimmons: ...<br> <fantasai> iank_: I'll try and channel Adam Argyle<br> <fantasai> iank_: He previously worked in industry and built lots and lots of Masonry layouts<br> <TabAtkins> Ah, I remember why *-content can't work for distributing the items in a masonry track!<br> <fantasai> iank_: he had similar reaction that might fit better as a separate layout model<br> <Rossen__> ack iank_<br> <Rossen__> ack dbaron<br> <Zakim> dbaron, you wanted to ask about which grid properties apply sensibly given the placement algorithm<br> <fantasai> dbaron: Jen was talking about, and think this might relate to Tab's comment on IRC, applying grid properties in vertical axis in masonry<br> <fantasai> dbaron: One thing I was wondering is how many interact with placement concept of Masonry<br> <fantasai> dbaron: e.g. if you have align-content in the vertical axis<br> <fantasai> dbaron: space-around, you want even gaps<br> <fantasai> dbaron: you don't know how many items until you place them<br> <hober> q+ myles<br> <fantasai> dbaron: and you can't place them until you know the number of gaps in each column above the item<br> <fantasai> TabAtkins: Mats answered it by saying you place items before applying align-content<br> <astearns> tantek: I don't think the flickr thing is masonry-row. The content order would go top to bottom in that case, and it looks to me like the first three pictures in the first row are in content order<br> <heycam> TabAtkins: align-content is a different thing, it moves the whole grid<br> <heycam> ... repeat autofill doesn't work<br> <fantasai> TabAtkins: But back to fantasai's point about align-content, in Grid it aligns the entire grid<br> <fantasai> florian: If you have a grid with sized tracks in the Block axis, and the size of the tracks is smaller than the container, then you can align<br> <fantasai> florian: but masonry tracks don't have such a size<br> <tantek> astearns, I have heard what Flickr does called "masonry" layout as well so that likely deserves some clarification<br> <tantek> in particular, the feature of resizing images to fit like that<br> <fantasai> TabAtkins: Track does have a size, it's the sum of all masonry items in it<br> <astearns> q+ to surface my side convo with tantek<br> <fantasai> myles: Want to jump on bandwagon and say it's really exciting<br> <fantasai> myles: wrt new display type, I think Mats makes a compelling argument wrt graceful degradation<br> <fantasai> fremy: you can just say `display: grid; display: masonry` which works<br> <Rossen__> ack myles<br> <fantasai> TabAtkins: Especially if we re-use grid-template-columns or whatever, it's easy fallback<br> <fantasai> astearns: Side conversation with Tantek on IRC<br> <fantasai> astearns: Has example of Flickr, wants to ask if that's also Masonry layout<br> <tantek> specifically with the resizing of items in the masonry layout<br> <tantek> yes dbaron<br> <fantasai> Rossen__: This is a multiline flex<br> <astearns> ack astearns<br> <Zakim> astearns, you wanted to surface my side convo with tantek<br> <fantasai> jensimmons: Flickr decides how many photos to put in a row<br> <fantasai> jensimmons: then makes the outer edges to match the container<br> <tantek> it's not just flex. it's about resizing the images automatically to fit them in the row<br> <fantasai> jensimmons: then changes the height of the row to match<br> <fantasai> jensimmons: it's weird and complicated and totally done in JS<br> <fantasai> dbaron: each image is sized based on other photos in the row<br> <tantek> anyway the point is due to the brick-like layout, this is *also* called masonry<br> <fantasai> jensimmons: If you [...] then you get basically that layout, but the images are cropped by object-fit<br> <fantasai> jensimmons: they use JS to avoid cropping the images<br> <fantasai> jensimmons: and Masonry is a whole different layout<br> <tantek> having the row heights adjust automatically is key<br> <tantek> I'm saying that web developers (some at least) know this as masonry as well<br> <tantek> so if you call something masonry, some may/will expect this to be supported<br> <fantasai> Rossen__: In summary, I'm hearing a lot of support for this proposal<br> <fantasai> Rossen__: reminds me of early days of Grid, when we proposed something<br> <fantasai> Rossen__: and 2nd model was proposed to add to it, at first seemed unlikely to fit<br> <fantasai> Rossen__: but ended up with a harmonious merge<br> <fantasai> Rossen__: Let's get something in a more spec-like proposal<br> <fantasai> Rossen__: then decide if it should fit into Grid, or should be its own thing<br> <jensimmons> The demo I was just talking about: https://labs.jensimmons.com/2016/examples/image-gallery-flexbox-1.html It only works in FIrefox because of the flexbox sizing bug of images in Chrome, Edge & Safari.<br> <fantasai> Rossen__: Are there parts that should be extensions to Grid?<br> <fantasai> Rossen__: I think it will take some time to figure out<br> <fantasai> Rossen__: but overall goal of proposal and exposure of topic is achieved in sense that there's a lot of support and demand for this, so let's continue working on this in a separate module for now to bake out the details and decide the next path forward<br> <fantasai> Rossen__: might be Grid, might be something else<br> <fantasai> Rossen__: sound good?<br> <fantasai> fantasai: +1<br> <tantek> +1<br> <bkardell_> ... and to double down on solving the general reordering issue?<br> <fantasai> Rossen__: So I propose we take a resolution to adopt Masonry layout and move from there.<br> <fantasai> fantasai: Who's editing<br> <fantasai> TabAtkins: I'll co-edit, but not primary edit<br> <fantasai> Rossen__: Mats?<br> <fantasai> dbaron: We might have to do some convincing<br> <fantasai> fantasai: I can edit.<br> <fantasai> RESOLVED: Adopt Masonry layout proposal, editors fantasai and Tab, and Mats if he's convinceable<br> <fantasai> bkardell_: Masonry isn't in content order<br> <dbaron> and Jen?<br> <fantasai> florian: yes and no, it's not a 1D thing, they're in 2D space<br> <fantasai> florian: but within that space they're in content order<br> <astearns> they are always top to bottom, not necessarily left to right<br> <fantasai> s/convinceable/convinceable, and Jen if she's allows/<br> <fantasai> ?<br> <bkardell_> for the record, not pushing back on 'this' - worried about the general space<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4650#issuecomment-577614598 using your GitHub account
Received on Thursday, 23 January 2020 10:13:00 UTC