Yes, for that specific example it works. But in general, this essentially deletes the UL from the layout entirely. It won't be stylable[0] and it won't dispatch UI events that occur on it specifically.
One example of a reason you might want such an element to still participate in layout is to use that element as an area highlighter. Or you might make it a scrollable section; subgrid makes sticky-header tables rather trivial to implement now.
[0] Well, I can't remember right now if it's unstylable or if its height just ends up zero, but either way, it might not be what you expect.
One subtle thing worth adding is that display: contents also changes how accessibility trees are constructed. The element is removed from the visual layout and from the accessibility tree in many browsers, so semantics like list grouping, landmarks, or ARIA roles can disappear unless you re-introduce them manually.
That’s why subgrid ends up filling a different niche: you preserve the DOM structure, preserve accessibility semantics, and still let the children participate in the parent’s track sizing. It costs more than contents, but it avoids a lot of the accidental side-effects that show up once you start mixing layout, semantics, and interactivity.
Yeah this is a good callout. My understanding is that display: contents is not meant to impact the accessibility tree but there is a long and ongoing history of browser bugs that make me not want to use it for elements that have an accessible role
And on the second one, you could use any other unit instead of fr for the image to set its width consistently, then fr on the text to have it use up whatever remains.
I also wasn't understanding the value looking at the first two examples, but the pricing packages example I do think I would struggle to implement in a clean way using traditional css.
When I see the grid syntax, I just wanna jump off a cliff. Who created this abomination and why? We need trials to check whether these were the output of humans or some synthetics pretending to be humans.
Isn't this also what container queries solve better? I guess maybe you want to be sure that the whole grid remains consistent instead of relying on individual containers possibly making their own decisions. So many new features to investigate, so little time :) https://codepen.io/web-dot-dev/pen/rNrbPQw
Container queries don't solve the responsive to sibling sizes issue that grid/flex can solve. And frustratingly container queries force your container element to be a new stacking context, unlike flex/grid.
I am sad that using containers and subgrids together doesn't work. Being able to query the size of the subgrid from a child element would be super powerful.
Yes and no. <table> layouts were a hack that solved a real problem but came with massive downsides. People didn’t tell you to not use <table> to lay out content because grids are bad (they are quite handy! take a look at Grid Systems by Josef Müller-Brockmann) but because <table> both posed technical and accessibility problems. A layout grid is not a table (or a <table
>). A table (with and without <>) comes with attached semantics, hierarchy, reading direction etc. and is extremely rigid, which makes it a bad fit for differing screen sizes.
It’s true that this was a blind spot for a long time and that it was frustrating to not be able to efficiently lay out content in 2D when <table> was just there. But it was the wrong choice then as it is now and it has been baseline available for 8 years now. I hope it won’t take another 8 years until the comparison stops :o)
I agree. I got really tired of hearing tables are for tabular data! For 20+ years. My reply was always, Who cares if it accomplished the layout you want. If the meaning of a word is what got people so hung up... why not go and make a new css term that did what tables did but improve on it. Now 20+ years later, that is pretty much what they did.
I use this thumb-rule while explaining them — Grid to Lay Layouts of distinct UI Blocks; while Flex is to layout contents, sometimes a continuous set of content.
Yeah, to expand on that... Flex is, well, flexible, whereas Grid is more rigid like a table. The rigidity of Grid allows you to span rows and columns (2D) just like you can with table cells (colspan/rowspan). Grid is usually used at a macro level for its more deterministic layout (no unintuitive flex quirks), while flex is usually used to lay things out at a component level where you don't care that the next row of items isn't perfectly aligned with the ones above (you will often see it hold some buttons or badges, or vertically align text to an icon), and Grid setting the layout of the app and container components (modals, cards, etc).
So is Grid supposed to be what we should use to replace the html <table> element? That I still use to this day for layouts because CSS still sucks to me?
No. The table is meant to hold tabular data like a spreadsheet. It has special behavior for people who use tools like screen readers because they have vision impairment.
CSS grid is a powerful layout tool. If you think CSS sucks I encourage you to brush up on the newer developments. Flex box and grid and many other newer tools solve a lot of the classic pain points with CSS and make it a pleasure to use if you invest the time to learn it
Use <table> for tabular data, but for layout you should use grid. Grid doesn't have it's own element like table does, so you have to use css to apply that display to a div.
CSS takes a bit of time to understand. It's cascading nature and how certain properties behave differently based on the html structure or display type or direction makes it tricky. I don't blame you sticking with tables for layouts for yourself - making layouts with floats was a pain. Bootstrap hid a lot of the layout pain. But today we have flex and grid to help us realize our layouts.
Subgrid is really cool, but I want to note that for the first trivial example, you could make the children participate in grid layout by doing
it's more efficient, if you don't need subgrid features, but still want the nested element structure for other reasons.Yes, for that specific example it works. But in general, this essentially deletes the UL from the layout entirely. It won't be stylable[0] and it won't dispatch UI events that occur on it specifically.
One example of a reason you might want such an element to still participate in layout is to use that element as an area highlighter. Or you might make it a scrollable section; subgrid makes sticky-header tables rather trivial to implement now.
[0] Well, I can't remember right now if it's unstylable or if its height just ends up zero, but either way, it might not be what you expect.
One subtle thing worth adding is that display: contents also changes how accessibility trees are constructed. The element is removed from the visual layout and from the accessibility tree in many browsers, so semantics like list grouping, landmarks, or ARIA roles can disappear unless you re-introduce them manually.
That’s why subgrid ends up filling a different niche: you preserve the DOM structure, preserve accessibility semantics, and still let the children participate in the parent’s track sizing. It costs more than contents, but it avoids a lot of the accidental side-effects that show up once you start mixing layout, semantics, and interactivity.
Yeah this is a good callout. My understanding is that display: contents is not meant to impact the accessibility tree but there is a long and ongoing history of browser bugs that make me not want to use it for elements that have an accessible role
And on the second one, you could use any other unit instead of fr for the image to set its width consistently, then fr on the text to have it use up whatever remains.
I also wasn't understanding the value looking at the first two examples, but the pricing packages example I do think I would struggle to implement in a clean way using traditional css.
When I see the grid syntax, I just wanna jump off a cliff. Who created this abomination and why? We need trials to check whether these were the output of humans or some synthetics pretending to be humans.
Isn't this also what container queries solve better? I guess maybe you want to be sure that the whole grid remains consistent instead of relying on individual containers possibly making their own decisions. So many new features to investigate, so little time :) https://codepen.io/web-dot-dev/pen/rNrbPQw
Container queries don't solve the responsive to sibling sizes issue that grid/flex can solve. And frustratingly container queries force your container element to be a new stacking context, unlike flex/grid.
I am sad that using containers and subgrids together doesn't work. Being able to query the size of the subgrid from a child element would be super powerful.
Have we wrapped all the way around to <table> layouts again?
Yes and no. <table> layouts were a hack that solved a real problem but came with massive downsides. People didn’t tell you to not use <table> to lay out content because grids are bad (they are quite handy! take a look at Grid Systems by Josef Müller-Brockmann) but because <table> both posed technical and accessibility problems. A layout grid is not a table (or a <table >). A table (with and without <>) comes with attached semantics, hierarchy, reading direction etc. and is extremely rigid, which makes it a bad fit for differing screen sizes.
It’s true that this was a blind spot for a long time and that it was frustrating to not be able to efficiently lay out content in 2D when <table> was just there. But it was the wrong choice then as it is now and it has been baseline available for 8 years now. I hope it won’t take another 8 years until the comparison stops :o)
> A layout grid is not a table
Ain't it? Rows and columns get you a table.
<table> was a problem because it described content, not style. There's nothing wrong with creating grids.
I agree. I got really tired of hearing tables are for tabular data! For 20+ years. My reply was always, Who cares if it accomplished the layout you want. If the meaning of a word is what got people so hung up... why not go and make a new css term that did what tables did but improve on it. Now 20+ years later, that is pretty much what they did.
I am continually in awe of Josh's blog posts, clarity of writing, sense of design, and fun interactive website.
You're killing it, Josh. Thank you for writing and teaching us.
Agreed. I’m happy to be on his mailing list. I’m always excited for a new Josh article
How is this different to, and better than using nested grids?
This is addressed in the article. This really shines when you have sibling dependent layouts.
is grid intended to replace flex at some point or live side by side
I use this thumb-rule while explaining them — Grid to Lay Layouts of distinct UI Blocks; while Flex is to layout contents, sometimes a continuous set of content.
They're complimentary. As a general (though not exclusive) rule, consider flex for one-dimensional layouts, and grids for two-dimensional layouts.
Yeah, to expand on that... Flex is, well, flexible, whereas Grid is more rigid like a table. The rigidity of Grid allows you to span rows and columns (2D) just like you can with table cells (colspan/rowspan). Grid is usually used at a macro level for its more deterministic layout (no unintuitive flex quirks), while flex is usually used to lay things out at a component level where you don't care that the next row of items isn't perfectly aligned with the ones above (you will often see it hold some buttons or badges, or vertically align text to an icon), and Grid setting the layout of the app and container components (modals, cards, etc).
So is Grid supposed to be what we should use to replace the html <table> element? That I still use to this day for layouts because CSS still sucks to me?
No. The table is meant to hold tabular data like a spreadsheet. It has special behavior for people who use tools like screen readers because they have vision impairment.
CSS grid is a powerful layout tool. If you think CSS sucks I encourage you to brush up on the newer developments. Flex box and grid and many other newer tools solve a lot of the classic pain points with CSS and make it a pleasure to use if you invest the time to learn it
Use <table> for tabular data, but for layout you should use grid. Grid doesn't have it's own element like table does, so you have to use css to apply that display to a div.
CSS takes a bit of time to understand. It's cascading nature and how certain properties behave differently based on the html structure or display type or direction makes it tricky. I don't blame you sticking with tables for layouts for yourself - making layouts with floats was a pain. Bootstrap hid a lot of the layout pain. But today we have flex and grid to help us realize our layouts.