You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-grid-3][masonry] Adjustments/additions to grid shorthanding #12023
Given the two-dimensional nature of Grid, the grid shorthand ends up being fairly confusing for Masonry, given that in masonry, we only care about one direction. Having a separate shorthand that only sets the pieces needed for masonry makes it much clearer what you are setting, and I found in writing tests, leads to less opportunity for error, which I suspect will be the case for authors, as well.
changed the title [-][css-grid-3][masonry] Adjustments to shorthanding[/-][+][css-grid-3][masonry] Adjustments to `grid` shorthanding[/+]on Oct 20, 2025
changed the title [-][css-grid-3][masonry] Adjustments to `grid` shorthanding[/-][+][css-grid-3][masonry] Adjustments/additions to `grid` shorthanding[/+]on Oct 20, 2025
@alisonmaher and I discussed this topic a bit, and we would like to propose that both grid and any possible grid-lanes shorthand we add will reset all the properties currently reset by grid as well as any possible grid-lanes-direction-type properties. If we end up with two different flow-control properties, whatever the shorthand syntax ends up being, both will get set to matching values (i.e. both will create a "waterfall" layout or both will create a "brick" layout). No longhand left behind, etc. ;)
The CSS Working Group just discussed [css-grid-3][masonry] Adjustments/additions to `grid` shorthanding, and agreed to the following:
RESOLVED: Both grid and any grid-lanes shorthand we introduce reset all of the container properties for both grid and grid-lanes.
RESOLVED: Pursue a grid-lanes shorthand syntax.
The full IRC log of that discussion
<sgill> scribe+
<fantasai> s/Topic/Subtopic
<sgill> fantasai: been some discussion about adding shorthand and new syntax to existing for grid lanes
<sgill> ... lots been up in the air because of debating grid lanes direction and auto flow stuff
<sgill> ... alisonmaher and I could resolve on which properties get reset by shorthands
<sgill> ... every property reset by the grid shorthand + any possible grid lanes flow / management properties get reset either grid shorthand and new shorthand
<sgill> astearns: can you go into why
<TabAtkins> q+
<sgill> fantasai: grid shorthand is grid by itself so resets that
<sgill> ... if we introduce a grid-lanes shorthand it functionally sets up rows or columns and secondary axis is automatic placement of some kind
<sgill> ... that is true whether you are in grid or grid-lanes layout
<astearns> q+
<sgill> ... can have type of layout where you have explicit tracks and you flow down the tracks
<sgill> ... only difference is whether you align along the rows of the secondary axis
<sgill> ... if we create the shorthand for grid-lanes it will already reset a bunch of grid properties
<sgill> ... might as well reset all of them so you actually get that layout
<sgill> ... display property becomes a switch on whether you create secondary tracks or not
<sgill> ... it is a really common pattern to want to do that in grid as well
<astearns> ack TabAtkins
<sgill> TabAtkins: while I don't think it's important to support between grid and grid lanes I think it's useful to have both the shorthands reset the same set of things
<sgill> ... we don't have much other examples of these shorthands resetting multiple things
<alisonmaher> q+
<sgill> ... potentially confusing have substantial overlap resetting both but not all
<sgill> astearns: iiuc the developer would you the display property switch and nothing else
<sgill> ... because if you are switching using the grid lanes shorthand you might be resetting things that the grid may want to use but grid lanes ignores
<sgill> TabAtkins: that is ok because the style rules setting up the grid styles would just return to applying when switch
<sgill> ... only one would apply at a time or one is overriding
<sgill> ... when you stop doing the style the base styles would still be in effect
<sgill> ... setting a shorthand isn't like assigning a variable
<astearns> ack alisonmaher
<astearns> ack astearns
<sgill> alisonmaher: reasonable to reset properties for both
<sgill> ... can we resolve on that we want a grid lanes shorthand with shape TBD
<sgill> fantasai: think we need syntax before we can resolve
<sgill> alisonmaher: in either case we want a grid lanes shorthand
<sgill> TabAtkins: still the case the grid shorthand is bad to use for grid lanes
<sgill> .... going to still need the new shorthand
<sgill> fantasai: ok with pursuing proposals for it
<sgill> ... working through syntax is going to depend on other stuff but whether or not we have it is not
<sgill> astearns: not convinced but mostly I don't care since it is a shorthand '
<sgill> PROPOSED: pursue a grid-lanes shorthand and both the grid and grid-lanes shorthand would reset all of the properties for both grid and grid-lanes. syntax TBD
<fantasai> PROPOSED: Both grid and any grid-lanes shorthand we introduce reset all of the container properties for both grid and grid-lanes.
<fantasai> RESOLVED: Both grid and any grid-lanes shorthand we introduce reset all of the container properties for both grid and grid-lanes.
<fantasai> PROPOSED: Pursue a grid-lanes shorthand syntax.
<fantasai> RESOLVED: Pursue a grid-lanes shorthand syntax.
Activity
alisonmaher commentedon Aug 17, 2025
In Chromium, we have a prototype of a separate
masonryshorthand: https://developer.chrome.com/blog/masonry-update#try-masonry (enabling the Masonry feature flag is required to play with it).Given the two-dimensional nature of Grid, the
gridshorthand ends up being fairly confusing for Masonry, given that in masonry, we only care about one direction. Having a separate shorthand that only sets the pieces needed for masonry makes it much clearer what you are setting, and I found in writing tests, leads to less opportunity for error, which I suspect will be the case for authors, as well.[-][css-grid-3][masonry] Adjustments to shorthanding[/-][+][css-grid-3][masonry] Adjustments to `grid` shorthanding[/+][-][css-grid-3][masonry] Adjustments to `grid` shorthanding[/-][+][css-grid-3][masonry] Adjustments/additions to `grid` shorthanding[/+]12 remaining items
Bug 2009030 [wpt PR 57050] - [Masonry] Add new 'normal' default to 'g…
[Masonry] Add new 'normal' default to 'grid-lanes-direction'
[Masonry] Update grid-lanes syntax
[Masonry] Update grid-lanes syntax
[Masonry] Update grid-lanes syntax
Bug 2013637 [wpt PR 57453] - [Masonry] Update grid-lanes syntax, a=te…
fantasai commentedon Jul 29, 2026
@alisonmaher and I discussed this topic a bit, and we would like to propose that both
gridand any possiblegrid-lanesshorthand we add will reset all the properties currently reset bygridas well as any possiblegrid-lanes-direction-type properties. If we end up with two different flow-control properties, whatever the shorthand syntax ends up being, both will get set to matching values (i.e. both will create a "waterfall" layout or both will create a "brick" layout). No longhand left behind, etc. ;)css-meeting-bot commentedon Aug 5, 2026
The CSS Working Group just discussed
[css-grid-3][masonry] Adjustments/additions to `grid` shorthanding, and agreed to the following:RESOLVED: Both grid and any grid-lanes shorthand we introduce reset all of the container properties for both grid and grid-lanes.RESOLVED: Pursue a grid-lanes shorthand syntax.The full IRC log of that discussion
<sgill> scribe+<fantasai> s/Topic/Subtopic
<sgill> fantasai: been some discussion about adding shorthand and new syntax to existing for grid lanes
<sgill> ... lots been up in the air because of debating grid lanes direction and auto flow stuff
<sgill> ... alisonmaher and I could resolve on which properties get reset by shorthands
<sgill> ... every property reset by the grid shorthand + any possible grid lanes flow / management properties get reset either grid shorthand and new shorthand
<sgill> astearns: can you go into why
<TabAtkins> q+
<sgill> fantasai: grid shorthand is grid by itself so resets that
<sgill> ... if we introduce a grid-lanes shorthand it functionally sets up rows or columns and secondary axis is automatic placement of some kind
<sgill> ... that is true whether you are in grid or grid-lanes layout
<astearns> q+
<sgill> ... can have type of layout where you have explicit tracks and you flow down the tracks
<sgill> ... only difference is whether you align along the rows of the secondary axis
<sgill> ... if we create the shorthand for grid-lanes it will already reset a bunch of grid properties
<sgill> ... might as well reset all of them so you actually get that layout
<sgill> ... display property becomes a switch on whether you create secondary tracks or not
<sgill> ... it is a really common pattern to want to do that in grid as well
<astearns> ack TabAtkins
<sgill> TabAtkins: while I don't think it's important to support between grid and grid lanes I think it's useful to have both the shorthands reset the same set of things
<sgill> ... we don't have much other examples of these shorthands resetting multiple things
<alisonmaher> q+
<sgill> ... potentially confusing have substantial overlap resetting both but not all
<sgill> astearns: iiuc the developer would you the display property switch and nothing else
<sgill> ... because if you are switching using the grid lanes shorthand you might be resetting things that the grid may want to use but grid lanes ignores
<sgill> TabAtkins: that is ok because the style rules setting up the grid styles would just return to applying when switch
<sgill> ... only one would apply at a time or one is overriding
<sgill> ... when you stop doing the style the base styles would still be in effect
<sgill> ... setting a shorthand isn't like assigning a variable
<astearns> ack alisonmaher
<astearns> ack astearns
<sgill> alisonmaher: reasonable to reset properties for both
<sgill> ... can we resolve on that we want a grid lanes shorthand with shape TBD
<sgill> fantasai: think we need syntax before we can resolve
<sgill> alisonmaher: in either case we want a grid lanes shorthand
<sgill> TabAtkins: still the case the grid shorthand is bad to use for grid lanes
<sgill> .... going to still need the new shorthand
<sgill> fantasai: ok with pursuing proposals for it
<sgill> ... working through syntax is going to depend on other stuff but whether or not we have it is not
<sgill> astearns: not convinced but mostly I don't care since it is a shorthand '
<sgill> PROPOSED: pursue a grid-lanes shorthand and both the grid and grid-lanes shorthand would reset all of the properties for both grid and grid-lanes. syntax TBD
<fantasai> PROPOSED: Both grid and any grid-lanes shorthand we introduce reset all of the container properties for both grid and grid-lanes.
<fantasai> RESOLVED: Both grid and any grid-lanes shorthand we introduce reset all of the container properties for both grid and grid-lanes.
<fantasai> PROPOSED: Pursue a grid-lanes shorthand syntax.
<fantasai> RESOLVED: Pursue a grid-lanes shorthand syntax.