- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Apr 2020 23:02:40 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Masonry Layout`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Masonry Layout<br> <fantasai> ScribeNick: fantasai<br> <bkardell_> I can try to step in - do I need to do anything to switch it<br> <fantasai> heycam: Small update since we last talked about this in A Coruña where jensimmons gave a great introduction<br> <fantasai> heycam: Since that time, Mats has done some refining of the idea in the issue<br> <fantasai> heycam: and has landed a prototype in Gecko<br> <jensimmons> here's an example: https://codepen.io/jensimmons/full/QWjqbJj<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4650<br> <fantasai> heycam: Want to get feedback<br> <fantasai> heycam: Also written up an explainer doc<br> <fantasai> heycam: Thought it might be helpful to have a more high-level description<br> <fantasai> heycam: so not wading through GH issue<br> <fantasai> heycam: Don't know whether ppl are wanting to dive into discussions about particular aspects of the proposal or not<br> <fantasai> heycam: Now that we have a prototype and an explainer, might be worth ppl filing individual issues against the proposal<br> <fantasai> astearns: definite +1 to individual issue<br> <astearns> ack fantasai<br> <dbaron> ScribeNick: dbaron<br> <dbaron> fantasai: great to have individual issues. Why not have a FPWD? We have agreed to work on it.<br> <fantasai> heycam: Seemed like ppl were not sure about whether this should be a grid feature or not<br> <dbaron> fantasai: when we come up with early stage work; we're often unsure about many things. Doesn't mean we don't draft it up and publish it.<br> <dbaron> AmeliaBR: can we agree to adopt this concept as described in this explainer as something we want written up in css-grid-2 spec or grid-3?<br> <fantasai> AmeliaBR: So question is can we agree to adopt what's writtenup?<br> <fantasai> fantasai: Thought we already agreed to adopt<br> <fantasai> heycam: Thought we only agreed on the idea<br> <fantasai> heycam: if ppl willing to resolve on, for now, keep this as something to the grid model<br> <fantasai> heycam: add to grid-3<br> <fantasai> astearns: We officially agreed to adopt and assigned editors<br> <fantasai> jensimmons: There seemed to be a lot of debate in the group about whether built on grid<br> <heycam> https://github.com/w3c/csswg-drafts/blob/master/css-grid-2/MASONRY-EXPLAINER.md<br> <fantasai> jensimmons: example, fallback is grid, very nice<br> <fantasai> jensimmons: idea that Mats had to use masonry as part of Grid spec means you get Masonry in one dimension while all power of grid in the other dimension<br> <heycam> jen's example: https://codepen.io/jensimmons/full/QWjqbJj<br> <fantasai> jensimmons: so rows can be masonry and columns are full power of grid<br> <fantasai> jensimmons: but other ideas, certain ppl very strongly held opinions<br> <fantasai> jensimmons: didn't like using Grid as the place to do masonry, wanted display: masonry<br> <fantasai> jensimmons: I've seen some reactions from folks on Twitter etc.<br> <fantasai> jensimmons: "you can already do this, why new thing", Well no you can't<br> <fantasai> jensimmons: they think of it as multicol or flexbox<br> <fantasai> jensimmons: Open question, should this be part of Grid<br> <fantasai> jensimmons: But enough of a disagreement that we weren't sure<br> <fantasai> florian: Remains an open question, will have to dive in at some late rpoint<br> <fantasai> florian: but even if it's an open question, can still decide if it starts in Grid 3 and split later or start later and merge later, but should put it somewhere<br> <fantasai> dbaron: Also one other distinction here, worth thinking about<br> <astearns> q?<br> <fantasai> dbaron: To what extent we want to put prototyping into formal spec language<br> <fantasai> dbaron: vs having documents about those things that are more example-driven<br> <fantasai> dbaron: some amount of formal spec language<br> <fantasai> dbaron: but serve a different audience as part of trying to solicit feedback from ppl who might use the thing<br> <dbaron> fantasai: I don't see why that needs to be a separate doc that's not adopted by the WG.<br> <dbaron> fantasai: I think publishing a side explainer that's not official work of the working group.... seems like not part of official work of WG.<br> <fantasai> iank_: Gives impression to Web devs that they can give feedback<br> <fantasai> dbaron: Just because it's an explainer doesn't mean it's not official working group work. It's in teh repo<br> <fantasai> fantasai: [said stuff]<br> <fantasai> dbaron: Idea of explainers was to address that problem<br> <fantasai> Rossen_: Seem to be getting off topic<br> <jensimmons> demo: https://codepen.io/jensimmons/pen/QWjqbJj?editors=1100<br> <fantasai> astearns: Let's put aside how we work and where work happens, look at demo<br> <fantasai> [technical difficulties]<br> <jensimmons> display: grid;<br> <jensimmons> grid-template-rows: masonry;<br> <jensimmons> grid-template-columns: repeat(auto-fill, 20rem);<br> <fantasai> jensimmons: Mats's design is elegant<br> <fantasai> jensimmons: Shape of this layout can be accomplished in multicol, but the ordering cannot<br> <fantasai> Rossen_: this is awesome<br> <fantasai> jensimmons: Responsive design style<br> <fantasai> jensimmons: narrower it's 2 col, wider is 4 or 5 columns<br> <fantasai> jensimmons: Content gets rearranged<br> <fantasai> jensimmons: but always in masonry style layout<br> <fantasai> jensimmons: One of the main reasons ppl keep doing this layout in JS is because of lazy-loading<br> <fantasai> jensimmons: They want to load new content into the bottom<br> <fantasai> jensimmons: using a proper masonry layout, first levels of content stay at the top, add to the bottom<br> <fantasai> jensimmons: with multicol, everything gets rearranged each time you add content<br> <fantasai> jensimmons: [shows code]<br> <fantasai> jensimmons: This one is auto-fill columns of even size, but could make different-sized columns... anything you can do in Grid, can do in Masonry layout<br> <fantasai> jensimmons: Fallback, if you open in current FF, has grid-template-rows: auto (default value), so everything lines up and just have extra space in the rows<br> <astearns> q?<br> <fantasai> Rossen_: Someone asked if only available for rows, suspect not<br> <fantasai> jensimmons: Could define columns as masonry<br> <fantasai> dholbert: works in either axis<br> <fantasai> jensimmons: what happens if you put in both axes<br> <fantasai> dholbert: you can't, fails in one<br> <fantasai> dholbert: probably behaves as none<br> <fantasai> AmeliaBR: Looking through explainer, thing that was new since last time I saw this is how this interacts with intrinsic sizing<br> <fantasai> AmeliaBR: and way it suggests is to just use the 1st item that goes in each column as the one that decides the size of that column<br> <fantasai> AmeliaBR: which I guess is similar to fixed mode for table column sizing<br> <fantasai> AmeliaBR: but it's a little weird, unsure if there are other solutions for it<br> <fantasai> heycam: You're right, hadn't thought about the analogy to fixed table layout<br> <fantasai> heycam: The grid items you know for sure will be in particular column, they're the only ones you can rely on to size the columns<br> <fantasai> heycam: can choose those that are placed in a particular column<br> <fantasai> heycam: or ones which by automatic placement<br> <fantasai> heycam: would go into a particular column<br> <fantasai> heycam: which is true of the items in the first row<br> <fantasai> heycam: Do agree it feels a bit odd, other items can't influence sizing<br> <fantasai> heycam: I think you can by forcing them to be in the top row with grid-placement properties maybe??<br> <fantasai> heycam: not sure what else you could do apart from not allowing grid items to influence sizes<br> <fantasai> AmeliaBR: question for those who know grid layout better than I do, when we have regular auto layout with intrinsic rows<br> <fantasai> AmeliaBR: How does that handle cycles<br> <heycam> fantasai: in grid layout, you have to do placement before you can do the sizing of the columns<br> <heycam> ... because the sizing can depend on what's in it<br> <heycam> ... grid placement doesn't depend on the size of anything<br> <heycam> ... you start putting things into slots, doesn't matter what the size of the item is<br> <heycam> ... that's not true of masonry layout, which is where this rule is coming in<br> <heycam> ... oyu need to know which column it's in to size it, but in order to size the column, you need to know what's in it<br> <heycam> ... so the proposal is using the items that we know will be in a particular column<br> <heycam> ... what we could do to do an initial sizing pass based on the items we know, with an explicit column or in top row<br> <heycam> ... then place all the items into appropriate columns, then run the grid sizing alg on all of the items<br> <heycam> ... so later items would also influence the size of the columns<br> <heycam> ... this could cause, depending on width -> height influences, could cause them to shift higher/lower in their columsn<br> <fantasai> AmeliaBR: Way they approached it, seems simple as anything<br> <dbaron> ScribeNick: fantasai<br> <fantasai> AmeliaBR: most of the time this layout seems to be used with fixed-width cols<br> <astearns> q?<br> <fantasai> florian: Also if we take fantasai's approach, probably want a switch it off, so that column heights can remain stable over time as you load comments<br> <astearns> ack fantasai<br> <fantasai> astearns: Comments on the proposal / demo?<br> <fantasai> astearns: I agree with fantasai that this should be in an official document. We did resolve on doing that<br> <fantasai> astearns: Let's open a separate issue for that quesiton<br> <fantasai> astearns: Let's assume it goes into css-grid-3<br> <fantasai> astearns: and have the issue have discussion for why that might not be the case<br> <fantasai> astearns: and come back to this next week<br> <fantasai> astearns: and decide if it goes into grid-3 or a separate module<br> <fantasai> astearns: put your arguments into the issue soon<br> <fantasai> astearns: Thanks for explainer, do like having a more generally-accessible version of our documents<br> <fantasai> astearns: I'm glad it's in our repo<br> <fantasai> astearns: and thanks for demo, cool to see<br> <fantasai> heycam: file specific issues on e.g. sizing<br> <fantasai> astearns: break up into subtopics will help, yes<br> <heycam> fantasai: I think we should be publishing our work, so we should also consider explaining the explainer either as a FPWD, or as a note at some point<br> <chris_> +1 for some more 4-hour meetings!<br> <dbaron> I think if we do ruby it should be at a later time than this, but some of the other issues should perhaps be at the early time.<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-622163998 using your GitHub account
Received on Thursday, 30 April 2020 23:02:43 UTC