- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 17 Dec 2025 16:52:27 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-grid-3][masonry] Adjustments/additions to `grid` shorthanding``, and agreed to the following: * `RESOLVED: Whether we add grid-lanes or not, grid (and grid-lanes) will reset all the container-set grid-* properties that apply to grid or grid-lanes layout.` <details><summary>The full IRC log of that discussion</summary> <Kurt> astearns: can we make progress without first one resovled?<br> <Kurt> fantasai: we can try, not sure if we'll be successful<br> <Kurt> fantasai: I tried to make a summary. I believe there are two proposals, one is to create a dedicated shorthand called grid-lanes. The other is reuse grid shorthand. I tried to summarize. They would mostly have the same syntax, but the grid shorthand would need a sentinel value to say that you're flipping into this variant, and B to indicate the<br> <Kurt> axis that you are setting the track for.<br> <Kurt> ...the grid-lanes shorthand reuses the grid-lanes-direction property<br> <Kurt> ...that's the high level summary, not sure we can solve it until we solve the other question<br> <Kurt> ...grid-lanes-direction sets flow value and tells parser which of rows or columns you will fill with track definition that follows<br> <fantasai> grid-lanes: row 100px 200px;<br> <fantasai> grid: rows 100px 200px;<br> <fantasai> grid-lanes: column 100px 200px "narrow" "wide";<br> <fantasai> grid: columns 100px 200px "narrow" "wide";<br> <Kurt> ...several questions: 1 - new property or existing<br> <Kurt> ...2: if we reuse grid, is the keyword rows and columns appropriate, representing suffix on template<br> <alisonmaher> q+<br> <Kurt> ...and then there's the area syntax, which Tab is interested in having a shorthand in order to unify how tracks are referenced in both axis<br> <Kurt> ...normal you create a little diagram, single string representing a column or multiple representing rows. I think we want to join all of the strings and apply them to the appropriate axis<br> <TabAtkins> (That use of multiple strings in the grid-lanes example is wrong; it should be one string.)<br> <astearns> ack florian<br> <astearns> ack alisonmaher<br> <florian> q-<br> <TabAtkins> (And in the 'grid' version it *also* should be one string; it's "brick" layout that ends up having multiple strings.)<br> <Kurt> alisonmaher: question about grid proposal - I see grid-auto-flow, but we also set the template - how does grid-auto-flow work?<br> <TabAtkins> q+<br> <Kurt> fantasai: if you set grid-auto-flow, it would set grid-auto-flow to that value. You won't need to do that unless you set dense packing, or if you are trying to reverse an axis. Waterfall, you want to reverse placement right to left buit it's stil top to bottom. Grid-column: columns track_list row-reverse.<br> <Kurt> alisonmaher: I think that could get confusing - as we discuss other issue, I think they're related and there are weird side effects of that proposal. You'd have different directionality. Considering both is important.<br> <astearns> ack TabAtkins<br> <Kurt> TabAtkins: I cannot find the other thread where I made this point - discussions span a bunch of threads. The big issue with reusing grid is that the grid shorthand is also really complicated. We did a bad job on it. it's complicated and authors avoid it. Adding a new branch will hurt it. It also means we'll have things in the grid syntax that<br> <Kurt> impact things that grid doesn't use like tolerance. Argument for reusing grid is bad for authors and technical standpoint. The only argument for it is we don't introduce a new property, which isn't a great argument.<br> <alisonmaher> strong +1<br> <Kurt> ...strongly in favor of grid-lanes. Should not expand grid.<br> <miriam> q+<br> <Kurt> +1<br> <astearns> ack miriam<br> <ydaniv> q+<br> <florian> q+<br> <Kurt> miriam: I agree that noone is using grid shorthand, or it's very rare. I will go as far as template in shorthanding grid. Curious here, this includes template. If I was still using the same grid-template shorthand that I've been using. I would be using the longhands whichever direction we go here. No strong preference, but I don't see any use in<br> <Kurt> putting it in grid.<br> <Kurt> astearns: Anyone who wants to argue for grid?<br> <astearns> ack ydaniv<br> <Kurt> ydaniv: as an author, I agree with Miriam. +1 to what Tab said, it's already complicated as it is<br> <Kurt> ...trying to build on top of grid is not a good case for simplifying<br> <astearns> q+<br> <Kurt> florian: I'm a little bit on the fence. On the one hand I agree, too much stuff in grid.<br> <astearns> ack florian<br> <Kurt> ...I wonder if a new one might suffer from the same problem<br> <Kurt> ...even if we design it slightly better, it might be confusing. If that is the case, why introduce another property? We could still make grid complete with the expectation that no one would use it.<br> <miriam> +1 florian, I don't expect I'd use either one of these<br> <TabAtkins> It's not the abstraction level, it's the complexity/fragility of the syntax - `grid` has to be written in very specific ways to invoke the different syntax branches, and breaks if you don't do it. `grid-lanes` will just be the standard "all properties in any order" behavior<br> <astearns> ack fantasai<br> <Kurt> fantasai: I think the argument for using grid shorthand is that it exists and resets properties we want to reset<br> <jensimmons> +1 to what Florian said<br> <Kurt> ...in terms of the complexity of the syntax of grid, Miriam uses grid-template syntax, grid is compatible with grid-template and will reset other properties. I think there's some confusion about using too specific of a shorthand. I agree with Tab that auto-flow syntax confuses people, and grid-lanes syntax with 1 keyword for direction and have<br> <Kurt> other syntax about direction than slash syntax is a better syntax that will be better for grid as well. Waterfall property for grid is the same properties for grid-lanes. You set one axis and let the properties to do their things. This is equally useful for grid for a common case of auto flow layout.<br> <Kurt> ...auto flow as added later in grid. I don't think that splitting it into its own shorthand gains you a lot. You could just teach "this is how you use grid lanes" and ignore the grid parts.<br> <Kurt> astearns: it was clear that Florian was advocating for stuffing grid-lanes into grid shorthand because no one would use it, or just not shorthanding grid-lanes. Can you clarify?<br> <astearns> ack astearns<br> <TabAtkins> Reminder of the current grid syntax: <https://drafts.csswg.org/css-grid-2/#grid-shorthand> 3 distinct syntax branches<br> <Kurt> Florian: not sure, would rather have in grid shorthand because if you just use it as a reset, it'll do the right thing, but I'm mainly making the argument that because we don't use grid doesn't mean we have to create something else no one will use<br> <Kurt> astearns: we could just decide not to have a grid-lanes shorthand at all yet and define later. We can figure out once we have implementations that work together in author's hands and have an idea of what they want the shorthand for<br> <Kurt> fantasai: Tab has a good idea of what authors might use it for - only one axis to set<br> <Kurt> TabAtkins: yes, and other masonry specific properties are straightforward to set as all<br> <Kurt> asteans: can we decide on one or the other?<br> <Kurt> florian: Not sure, your proposal only makes sense in one case of the longhand syntax. If we go with B1, we could punt and set the right things anyways, could expand later. If we go with A syntax, we want grid to at least reset properties, even if we decide to expand neither, or introducing grid lanes. In either case, we want grid to reset<br> <Kurt> everything.<br> <Kurt> TabAktkins: This argument applies regardless of flow direction. Current grid syntax of auto flow is actively bad. Using that for masonry is a bad thing.<br> <ydaniv> q+<br> <Kurt> Florian: What I'm saying is if we are open to A over B1 and we're over to taking grid-lanes shorthand, I would also want grid-lanes shorthand to reset all shorthands. If we go with B1, we don't have to, but if we go in the other direction, we also want to.<br> <Kurt> TabAtkins: The threshold needs to be reset. Dealing with that is ok.<br> <astearns> ack ydaniv<br> <Kurt> ydaniv: Agree with what Alan suggested - don't shorthand and wait for cow trails to see if people ask for shorthand to do whatever, reset, etc and point to the right direction. Can do better.<br> <fantasai> PROPOSED: Whether we add grid-lanes or not, grid (and grid-lanes) will reset all the container-set grid-* properties that apply to grid or grid-lanes layout.<br> <Kurt> TabAtkins: Even if we decide to do a different thing for auto flowing in masonry, I'm fine if we end up resolving that template for masonry gets reset for grid given that grid shorthand resets a couple properties. Given the interweaving, I'm comfortable with either shorthand resetting all of the same properties, even if it's not the same.<br> <TabAtkins> +1 to proposed from fantasai<br> <Kurt> Florian: if we take what Alan and ydaniv propose, which is not to do a shorthand for now, I'd like to at least resolve that the grid shorthand resets all of the relevant shorthands<br> <Kurt> astearns: I think this indicates we don't introduce a grid-lanes shorthands<br> <Kurt> fantasai: not sure if it does one way or another<br> <Kurt> RESOLVED: Whether we add grid-lanes or not, grid (and grid-lanes) will reset all the container-set grid-* properties that apply to grid or grid-lanes layout.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12023#issuecomment-3666247995 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 December 2025 16:52:28 UTC