- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 20 Oct 2020 20:43:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Masonry Layout`, and agreed to the following: * `RESOLVED: Adopt Mats's draft as ED` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Masonry Layout<br> <fantasai> ScribeNick: fantasai<br> <chrishtr> Chris Harrelson, Google<br> <fantasai> mats_: I wrote the Masonry spec<br> <fantasai> https://raw.githack.com/mozilla/gecko-dev/master/layout/docs/css-grid-3/Overview.html<br> <fantasai> mats_: That's what we'll discuss today. I didn't prepare any presentatin of it, but happy to answer any technical questions you might have<br> <fantasai> heycam: Last time I presented the explainer based on Mats's gh issue<br> <fantasai> heycam: Mats turned that into spec text<br> <fantasai> heycam: Main thing we want today is, ask to put this into a draft<br> <fantasai> heycam: and secondly, which spec does that go into<br> <fantasai> heycam: is it Grid 3 or something else<br> <fantasai> Rossen_: Last time discussed in F2F, was at Igalia<br> <fantasai> Rossen_: Have there been any major changes since then?<br> <fantasai> Rossen_: Some of the early conversation was should it be part of grid or own display value.<br> <fantasai> Rossen_: Did we resolve on this? Current proposal uses grid<br> <fantasai> fantasai is in favor of using grid<br> <fantasai> heycam: That hasn't changed in the spec<br> <TabAtkins> q+<br> <jensimmons> q+<br> <fantasai> heycam: Initial proposal was tied into grid and not a separate layout model<br> <fantasai> heycam: Not sure if that's captured as an issue in the spec itself<br> <fantasai> heycam: Mats, could you talk about open issues listed in the spec?<br> <fantasai> mats_: [garbled]<br> <fantasai> mats_: A few issues in the spec, but mostly resolving edge cases<br> <fantasai> Rossen_: We should make the issue clear<br> <fantasai> Rossen_: Do we want to adopt this module?<br> <fantasai> heycam: Maybe easier to resolve on that first, then file specific issues in GH<br> <Rossen_> q?<br> <fantasai> iank_: Unsure if there was much follow-up discussion about in grid vs separate display tpe<br> <fantasai> s/tpe/type<br> <chrishtr> q+<br> <fremy> q+<br> <Rossen_> ack TabAtkins<br> <fantasai> TabAtkins: First, I was looking for where the proposal was and had trouble finding it. Have URL now<br> <fantasai> TabAtkins: looking in the thread, back in January we already agreed to adopt this proposal<br> <fantasai> TabAtkins: editors me, mats, fantasai, jensimmons<br> <fantasai> TabAtkins: We haven't done anything with it, but it seems like we already agreed to adopt it<br> <fantasai> TabAtkins: so should dive into structural questions like is it grid or not<br> <Rossen_> ack jensimmons<br> <fantasai> jensimmons: So not even sure what we're debating, but have comments on whether should be part of grid display type or own display type<br> <fantasai> jensimmons: Seems we haven't resolved that<br> <fantasai> jensimmons: I think it should be part of the grid display tpe<br> <fantasai> jensimmons: I really like how this proposal works. Read it again today.<br> <fantasai> jensimmons: I've been thinking about it the last few months, but re-reading again<br> <fantasai> jensimmons: think it would be awful lot of work to figure out making it not grid, in the other dimension etc.<br> <fantasai> jensimmons: and would perhaps settle on something simplistic<br> <iank_> q+<br> <fantasai> jensimmons: by making part of Grid, get an incredible body of work, resolved on gaps, alignment, repetition of tracks, etc.<br> <TabAtkins> If we did it as a separate thing, we would explicitly just do "exactly what Grid does" in everything that overlaps.<br> <fantasai> jensimmons: using minmax, etc.<br> <fantasai> jensimmons: Don't know why we would want to give authors a separate set of tools<br> <fantasai> jensimmons: Don't want to give authors two sets of things to learn<br> <fantasai> jensimmons: Argument from before, word "grid" means everything lines up in 2D but masonry is packing<br> <fantasai> jensimmons: but I think that's a pedantic argument<br> <florian> q+<br> <TabAtkins> It would just let us get a slightly more optimized syntax for declaring the masonry, basically.<br> <fantasai> jensimmons: I don't think "grid" can't encompass this<br> <fantasai> jensimmons: I think it should be part of grid, and I really like the direction this is going so far<br> <Rossen_> ack chrishtr<br> <fantasai> chrishtr: I'm wondering if, related to point already made about relation to grid, do you have data to show about how hard to implement or how much it re-uses the concept of grid?<br> <fantasai> mats_: It was pretty easy to fit into existing CSS grid code that we have<br> <fantasai> mats_: CSS grid, all the algorithms, are pretty standalone per axis<br> <fremy> q!<br> <fantasai> mats_: so our code at least, just run the code for one axis<br> <fantasai> mats_: ...<br> <fantasai> mats_: It shouldn't be hard<br> <fantasai> mats_: to implement for an existing CSS Grid implementatin<br> <fremy> fantasai: what's the keyword for moving yourself at the bacvk of the queue again?<br> <fantasai> mats_: get a lot of free structural [?]<br> <Rossen_> ack fremy<br> <fremy> q+<br> <fantasai> iank_: I think my concerns from last time still hold<br> <fantasai> iank_: Unless I'm wrong, a few things in the grid model that not in the masonry model<br> <fantasai> iank_: e.g. grid-area<br> <fantasai> iank_: right?<br> <fantasai> iank_: If I have grid-area: 1/2 it will ignore one of the axes<br> <TabAtkins> I strongly suspect we'd just literally build Masonry stuff into the Grid Layout Algo, even if we did Masonry as a separate spec.<br> <Rossen_> q?<br> <Rossen_> ack iank_<br> <fantasai> mats_: yes<br> <fantasai> iank_: That concerns me<br> <fantasai> iank_: Also, want to do things like splitting content over two grid areas<br> <fantasai> iank_: can re-use concepts<br> <fantasai> iank_: but I'd be hesitant to jump the gate<br> <fantasai> florian: I agree more with Jen than Ian<br> <fantasai> florian: Almost all the tools that work in Grid also should work here<br> <fantasai> florian: So theoretically we could have 'display: masonry' that either uses all the grid properties or has duplicate properties<br> <chris> q?<br> <fantasai> florian: but do we really need this?<br> <fantasai> florian: Having a few properties not apply some of the time is really OK<br> <TabAtkins> q+ about the set of properties applying to grid vs masonry<br> <Rossen_> q?<br> <fantasai> florian: Other question, If you're trying to fall back from masonry, what happens?<br> <Rossen_> ack florian<br> <TabAtkins> q+<br> <fantasai> florian: If separate display type, you fall back to block. Grid is probably a better naive fallback.<br> <fantasai> florian: But I'm leaning towards keeping it a grid variation rather than a separate thing<br> <fantasai> florian: and not too concerned about Ian's concern<br> <fremy> q- later<br> <TabAtkins> fantasai: I also think it makes sense to integrate it with grid, for all the reasons mentioned<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: in terms of various things not applying, if we wantt hem to apply i think we could have a masonry layout and grid layout if we wanted to<br> <TabAtkins> fantasai: So if you assign it to row 1 it's in a masonry layout in row 1, then if you put it in row 2 it's in a separate masonry layout<br> <TabAtkins> fantasai: Woudl be happy to adopt as an ED and possibly as a fpwd<br> <Rossen_> ack TabAtkins<br> <fantasai> TabAtkins: Looking over the set of grid properties and whether or not they apply<br> <fantasai> TabAtkins: It is absolutely the case that Masonry should be built on Grid algorithm<br> <fantasai> TabAtkins: but as for property set<br> <fantasai> TabAtkins: Most of them will have weirdness that only one of the pair works in masonry layout<br> <fantasai> TabAtkins: grid-auto-rows vs grid-auto-columns<br> <fantasai> TabAtkins: We have different flow values for masonry that do something similar but distinct<br> <fantasai> TabAtkins: similar to placement properties<br> <fantasai> TabAtkins: and then I guess row gap vs column gap work similarly<br> <fantasai> TabAtkins: I think we should make a new display value with its own properties<br> <fantasai> TabAtkins: but have a single layout algorithm<br> <fantasai> TabAtkins: but I think we have a good opportunity to have a better developer-facing API instead of trying to re-use and half-ignore the grid properties.<br> <Rossen_> q?<br> <fantasai> TabAtkins: but happy to be wrong, but I want to play around with making a new set of things just in case<br> <Rossen_> ack fremy<br> <fantasai> fremy: I think I agree with Tab on this mostly<br> <fantasai> fremy: but also, want to accept as WD<br> <fantasai> fremy: I took a look, there's like one new property, masonry-auto-flow<br> <fantasai> fremy: but no definition of what the values do<br> <fantasai> fremy: Hesitant to accept when there's no definition<br> <fantasai> fremy: I feel like it's not working great<br> <fantasai> fremy: So leaning towards saying, let's make this something different and if in the end we find we re-use most of the things<br> <myles> q+<br> <fantasai> fremy: but first let's define standalone and then later on if we find convergence, I think it would be more logical<br> <Rossen_> ack myles<br> <fantasai> myles: Understand idea that some grid properties won't apply to masonry. And in the future, some masonry properties won't apply to grid either<br> <fantasai> myles: And understand argument that even if different specs, even if properties with different names in different specs, can share algorithm<br> <fantasai> myles: The strongest differentiator between the two solutions is what the fallback is<br> <fantasai> myles: is it better to have masonry fall back to block, or to have some properties that apply just to grid<br> <TabAtkins> q+<br> <fantasai> myles: If masonry layout falls back to block, much worse than falling back to grid with some properties ignored<br> <fantasai> fremy: You can also fall back using @supports<br> <fantasai> fremy: There's no good reason to limit yourself because of fallback<br> <iank_> ```display: grid; display: masonry;``` is what a lot of folks will do for this case.<br> <fantasai> fremy: Even if the properties work similarly, not quite the same<br> <fantasai> myles: The argument there is about what authors get by default<br> <Rossen_> ack TabAtkins<br> <jensimmons> q+<br> <fantasai> myles: of course you can do anything, but what about authors who don't think about these cases<br> <fantasai> TabAtkins: This is the same argument that led to multicol being built on block and not being a separate display tpe<br> <fantasai> TabAtkins: Multicol is different of block, and having one be variant of other is weird<br> <florian> q?<br> <fantasai> TabAtkins: The fact that it's a "block container" is awkward, and I'm afraid we'll run into the same problem again<br> <fantasai> TabAtkins: But because going to be slightly different<br> <fantasai> TabAtkins: I suspect we'll end up writing ourselves into awkward corners if one different from other<br> <fantasai> heycam: I think the comparison to multicol is interesting in another way because we have this precedent of having the gap properties, which apply to flex and grid etc.<br> <fantasai> heycam: we gave them one name to apply across multiple layout models<br> <fantasai> heycam: Here we have grid-specific properties, but if we considered masonry separate from grid<br> <fantasai> heycam: names ... obvious<br> <fantasai> Rossen_: Want to make the discussion more action-oriented. Repeating previous discussions<br> <heycam> s/names ... obvious/names of some grid properties could be changed so that the commonalities are more obvious/<br> <fantasai> Rossen_: want to make sure we arrive at an actual resolution of what we're doing with the current spec<br> <fantasai> Rossen_: keep separating the leading sort of differences on the table<br> <fantasai> Rossen_: implementers and what they prefer vs. fallback mechanism vs. users and authors and how they will perceive from an ergonomic point of view<br> <Rossen_> ack jensimmons<br> <fantasai> jensimmons: The way I see it, alignment was created to go with flexbox and then folks realized it would be great to do in grid<br> <fantasai> jensimmons: and rather than come up with new set of keywords and values, because they do work slightly differently<br> <heycam> github: https://github.com/w3c/csswg-drafts/issues/4650<br> <fantasai> jensimmons: but the argument that authors, it'll be too hard to say 'grid-template-rows: masonry' and then 'grid-auto-rows: ??' to set the default<br> <fantasai> jensimmons: but 'grid-auto-rows' doesn't aply<br> <fantasai> jensimmons: I don't think authors will be confused<br> <fantasai> jensimmons: to me it's very similar to alignment<br> <Rossen_> q?<br> <fantasai> jensimmons: for alignment, making a separate set of syntax would have been much much more confusing<br> <fantasai> jensimmons: I'm really glad they share syntax<br> <fantasai> jensimmons: and that's my thought son this<br> <fantasai> jensimmons: It doesn't seem like a completely different layout model<br> <fantasai> jensimmons: It's an option in something bigger<br> <fantasai> jensimmons: and that is something that looks a lot like grid<br> <fantasai> jensimmons: Don't want duplication, new set of names and properties, etc.<br> <fantasai> jensimmons: Not just doing the simplest things possible in masonry.js, but much more powerful because built on Grid<br> <TabAtkins> fantasai: my proposal is that we adopt this as an ED, and i dont' reallyc are if we temporarily name it css-masonry or css-grid-3<br> <TabAtkins> fantasai: and think we should fill out the missing dfns, etc<br> <TabAtkins> fantasai: and come back to this topic and decide if we want to take it as fpwd as either name, and let Tab try his attempt at different names, let Jen survey authors, and come back to it in a month or two<br> <TabAtkins> fantasai: but adopt it for now as an official ed<br> <TabAtkins> fantasai: It'll be a diff spec built on top of grid anyway, at least at first<br> <florian> +1<br> <fantasai> fantasai: and publish FPWD when we think we're ready to show something to the world<br> <fantasai> Rossen_: Internally uses grid, but also is masonry layout<br> <fantasai> Rossen_: suggest adopt as-is and then decide upon FPWD<br> <fantasai> myles: We support progress on Masonry, and agree with fantasai, let's take the step we can take immediately<br> <fantasai> Rossen_: and might have other things to add to css-grid-3 also<br> <fantasai> fantasai: We have a list of stuff that's going into Grid 3 already, already resolved, just needs edits ...<br> <fantasai> RESOLVED: Adopt Mats's draft as ED<br> <fantasai> Rossen_: Mats, before you transition over, do you want to add the rest of the editors to this spec?<br> <fantasai> Rossen_: Jen, are you up to it?<br> <fantasai> jensimmons: yes, I would love to! yay new company that let's me do things<br> <fantasai> heycam: Firefox has recently gained a new experiments stage in the preferences<br> <fantasai> s/company/boss/<br> <fantasai> heycam: can turn it on and play with it<br> <fantasai> heycam: Settings options preferences<br> <fantasai> heycam: I think you have to be using Nightly<br> <fremy> q+<br> <Rossen_> ack fremy<br> <fantasai> fremy: Now that we adopted the ED, that sounds cool, but would like to discuss content of the draft<br> <fantasai> fremy: I'm not sure I understand the reason why we have all the keywords in 'masonry-auto-flow'<br> <fantasai> fremy: But reading the algorithms section, I'm not sure what's the goal<br> <fantasai> fremy: I think it would be a good idea to clarify a bit<br> <fantasai> Rossen_: We'll have the ED in the csswg repo pretty soon, hopefully by the end of the week<br> <fantasai> Rossen_: once this is the case, you can go ahead and file as many issues as you want<br> <fantasai> Rossen_: First issue might be display type<br> <fantasai> Rossen_: as well as everything else that is currently unclear, but at this point spent a lot of time and other agenda items<br> <fantasai> Rossen_: so please open issues<br> <fantasai> fremy: sure<br> <Rossen_> q?<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-713128263 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 20 October 2020 20:43:23 UTC