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
From my testing, as far as I've been able to tell it no longer has any impact on accessibility. The element itself does not appear in the tree, this makes sense display:contents is non-interactive. But all of the children correctly appear in the accessibility tree as if they did not have that shared parent element. But I am by no means an expert at operating screen readers, do you know of any specific issues with it?
Yeah, though I find in practice I use `display: contents` far more than I do subgrid. Contents effectively deletes the node for layout purposes, but it still participates in the CSS cascade so you can use it in selectors, even `:hover` works when a child gets hovered, or use it as the origin for inheritable properties.
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.
The pricing UI example is exactly the type of thing I had to build a few years ago. Deceptively simple, two tables for comparison, but the rows need to line up.
Impossible without subgrid, either you need to have fixed heights or calculate heights with JS, but neither is elegant or simple, especially if you have react components and adhere to modular design, and you need to have those components agree on sizing.
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)
They don't! Layout grids are less about the rows and columns and more about the lines separating them (which is why those get a lot of attention in CSS grid). Take a look at how layout grids are used in design and you will quickly find examples that are extremely inconvenient to realize with HTML tables. I'm sure it can be done and I'm sure some poor email marketing dev had to, but the result would be entirely static and not able to reflow.
You have just restated the similarity I referred to. The ways they are different make them important enough to distinguish.
“Tabulate” doesn’t just mean organising anything by rows and columns, it means organising data for a particular purpose. And layout grids usually end up looking quite different to tables because although they have a broadly similar underlying structure, the purpose is quite different.
They're not quite deprecated, but they're also not quite not deprecated at all:
> Historically, the <b> element was meant to make text boldface. Styling information has been deprecated since HTML4, so the meaning of the <b> element has been changed.
I think CSS grid is too powerful to be represented in markup. I rotated the idea in my head for a bit but the most I could come up was elements that covered a small subset of CSS grid and which completely lost the entire appeal of being able to handle tracks dynamically.
This is a classic problem I identify across a wide variety of types of software. I call it "forcing a graph into a tree" and it comes up any time you have something that must be evaluated across multiple axises but the earliest assumptions (now invalidated) about the data restricted it to a tree, or the most really available tools to process it is with tree-like data structures and algorithms.
HTML is a tree. It's really great at trees. But defining a grid layout sometimes requires organizing data by both the rows and the columns. That can't fit into a tree.
I think a lot of people's complaints that "CSS is too complex, why can't we just do this in HTML" would go away if they could understand that CSS--being a rules-based system--can process the graph, but HTML can only ever define a tree. There are things that will just never work in just HTML.
This gets hard because trees are easy for people to understand. We have lots of examples of them: file systems (if you ignore symlinks). Family trees (if you ignore inbreeding). Tree of life taxonomies (if you ignore more than basic undergrad biology). You can probably guess by my caveats how much I feel it is important to study graphs. But graphs are "scary Computer Science" stuff to a lot of people, so they don't take the time to learn.
Yes. I built layouts like this with automatic server-rendered tables 25 years ago, and they just worked with very little effort.
Tables weren't responsive or accessible or any of the other things we now recognize as essential, but it has certainly taken a long time to reinvent the table wheel. And all the while we've had to listen to people screaming in our ears that tables were bad, while also listening to them argue about which of their incredibly difficult and patently subpar "solutions" we were supposed to use instead.
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.
Random grid gotcha that drove me crazy some time ago: due to browser bugs we can't use <img> elements with percentage widths or heights as grid items. The grid cell dimensions get blown out to the ones of the original image. Seen in both Firefox and Chromium. Relevant FF bug is probably https://bugzilla.mozilla.org/show_bug.cgi?id=1857365 '<img> grid item with percentage height, "width: auto", "grid-template-columns: auto", and no track stretching makes column to have the same width of the original image's width' (although someone there claims it works in Chromium).
This sounds useful, but the example of the feature rows reminds me how sad it is that CSS sometimes requires adding information about the document structure to make a layout work. In this case the number of rows.
Ideally, we would have a way to align elements even when they don't share a parent. Or maybe a flex container that can have its layout mimic another flex container so the distribution in them can line up. It seems that there are a lot of heuristics and edge cases though to keep a simple DX.
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.
Why does it need explaining, when it has to be self explaining and not some overcomplicated mishmash. Like someone was under the influence of psychedelics when working out the specifics.
We had to wait 15 years for proper positioning in css. Same shit repeated again.
So it went thru multiple people and they all said in unison: well, this is all ironed out, easy to use and looks ok. We did a great job!
Just mind boggling. I get it, maybe they want to create extra jobs, by adding complexity, hence more people are required for a role, but why keeping up the illusion? Fucking alter the economic systems if this was the goal.
I think Flexbox is so much worse than CSS Grid. If Flexbox makes sense to you, it I don't think it should be that hard to learn CSS Grid, you'll already have many of the properties you need to understood learned. Grid just works properly in 2 whole dimensions where Flexbox sort of gives up after 1 and a half dimensions.
I sympathize with your comment and imagine the overflowing downvotes as soon you openly critic the web/css/javascript and their people doing the standard. I watched tons of videos and read a lot on mdn about css grid, I don't touch it for a while I need to go back at it again... After tables/floats/abs positioning eventually convoluted flex we should have stopped and review what the heck people were doing on w3c, it's artificial complexity we don't deserve that
There's plenty of overlap, but they solve different problems: flexbox when the content should control element sizing/fit, grid when the container should control element sizing/fit.
Another way to think about it: flexbox is for alignment of boxes in one dimension: horizontally or vertically.
CSS Grid is for two dimensional layout of rows and columns.
Back in the day, developers wanted page layout instead of the hacks on top of hacks with table-based layouts, floats and positioning to create layouts.
We’ve had CSS Grid designed for page layout on the web, in all browsers since 2017; as of 2022, only 12% of the top 1 million websites used CSS Grid, which to me is ridiculously low.
I use flexbox for grid purposes, simply because the syntax is straightforward and easy to read. Yeah, it’s one dimension, but if you nest it, it becomes two with no issues.
With nested flexbox the nested dimensions are not aligned to each other.
With grid the items are aligned across both each row AND each column.
With subgrid even nested grids can be aligned across nesting levels.
I think the grid syntax is really off-putting - it’s one of the few places of “typical” CSS I tend to avoid unless something really calls for it. In my experience, it feels like the people most familiar with grid display, the syntax, and using it, are more on the design side than the programming side - most of my frontend peers who use it tend to misuse it when flex would work fine and be less rigid for their goals
I agree. I occasionally turn to them to see if they work in a new setting, but find they never expose the features of a grid I would find useful. Everything must be manually placed, rather than allowing content to intelligently snap to multiple axes. Possibly I never have grasped some fundamental concept, possibly they are not suited to the sorts of layouts I usually work on. But more and more I feel they are designed to fulfil some purpose orthogonal to what I would need them to do.
Sounds like a source of bugs. Basically this means the grids can be nested to no end. It breaks locality in that now I have to understand what the parent would do before I can make sense of a component.
Why do you put styles in the code playground HTML and CSS file? I was staring at the first subgrid example’s CSS file for ages trying to figure how anything special was applied to the ul element.
Am I the only one who sees "content boxes"/divs with content displayed in different widths as poor design? At least in the example given, I would think you would want the image and its associated content box to be the same size for all four and not have its content vary in width based on how much content it has.
But in terms of functionality, I'm sure there are plenty applications for this!
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?
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.
There were back in CSS 2 display values for table, table cell, table row etc which meant you could make divs or other block elements layout like tables did. Of course it wasn't supported in a certain browser with 90% market share.
> Grid doesn't have it's own element like table does, so you have to use css to apply that display to a div.
Well, OOTB, yeah. I personally like to make use of custom html elements a lot of the time for such things. Such as <main-header> <main-footer> <main-content> <content-header> etc, and apply css styles to those, rather than putting in classes onto divs. Feels a lot more ergonomic to me. Also gives more meaningful markup in the html. (and forces me to name the actual tags so I use much less unnecessary ones)
Recent React round-trips custom elements better now. You just have to remember the standard's rule that all custom elements need to be named with dash (-) inside them.
It's more like a comic book, you define the layout and the elements slot into that. You can define how many rows and columns your comic has and then you can make some panels fit exactly into one spot, or you can have panels that span more than one row or column. So it's more of a 2d design system.
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
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.
I swear you that I had less hard time reading x86 assembly code or even c++ templates. I mean what the hell? Then if you go look at another example:
> @media (max-width: 32rem)
I know what rem means, I just don't know what the hell MAY mean, that alone in a big project will make you hate your job as sometimes it's more easier predicting what the response of an LLM may be than what styling an element will have on a live page
[Edit] I'm not confusing rem with em, em are even worse, but still hard predicting what a rem might be, before arguing we shouldn't I'd like to stress out we should once it's used like that "@media (max-width: 32rem)"
[Edit2] Instead of just downvoting why don't you reply with your counter arguments? I really am interested in hearing what you have to say
Grid is a DSL certainly, but it's a very useful DSL to learn. I'd even argue that people skip Flexbox or forget everything they (think they) know about Flexbox and just learn CSS Grid.
> I'm not confusing rem with em, em are even worse, but still hard predicting what a rem might be, before arguing we shouldn't I'd like to stress out we should once it's used like that "@media (max-width: 32rem)"
`rem` is "just" the root Em, the em in the root font size (the font size of the `<html>` tag itself). In most browsers, with no `<html style="font-size: X;">` override (or `:root { font-size: X; }` stylesheet) that defaults to 16px.
In the Bootstrap 3/4-era responsive breakpoints you often see something like `@media (max-width: 512px) {}` to mean "mobile width". The reasons to migrate those sort of breakpoints to `rem` units instead include 1) adapts to custom browser settings (a user may set their default font size larger, for instance, for visual acuity reasons, which can be a useful accessibility desire), 2) adapts in some situations to zoom settings (browsers are allowed to style the website at a higher zoom as if the user had chosen an equivalent larger base font size), and 3) in the "retina screen" world where resolutions on a phone screen may be higher than desktop resolutions despite smaller screen size, using "roughly 32 `M` characters wide" is a better intuition than "exactly 512px wide" (and mobile browsers can lie a bit less about their pixel widths to meet your breakpoint assumptions).
You can back-of-the-envelope math `X rem * 16 px/rem` to get a pixel approximation if you need one, and that estimate will hold in a lot of cases in a majority of browsers, but leaves the browser more flexibility in adapting to adapting to user desires and hardware quirks than raw pixel counts.
thanks for the lesson, not needed because i know how to do a multiplication, but oh well people need to flex their domain knowledge. You're missing the whole point: drid dsl is overengineered and convoluted with browser behaving differently on some cases. Css is a disease
Put me on a C++/asm project and I'd have a hard time making heads or tails of it. So what? Your comment comes off as very angry without any meaningful critique of the article's central topic other than you had a hard time understanding it.
1rem is equal to the same number of pixels anywhere on a given page and, generally speaking, across pages on a given site. If you don't know what the value is it only takes a minute to find out. If you're writing CSS that'll be used on unknown pages, you either a) shouldn't care and just scale relative to whatever root font size the consumer set or b) should set your own size/scale, at build time or with custom properties. REMs have been around and standard practice for 10 years.
> 1rem is equal to the same number of pixels anywhere on a given page and, generally speaking, across pages on a given site.
That's not true, first of all the root font size might not be immediate to query and find out what it is, second it might change because of variables on the root or base font size might be percentage/rem based itself not necessarily in pixels and finally setting it in pixels doesn't take into consideration zoom levels, or OS-level font settings.
> REMs have been around and standard practice for 10 years.
I know but thanks for flexing it out, in fact I'm arguing that css is and has been bad for many years
My point was that there is only one root font size on a given page and it's trivial to find out what that is by looking in dev tools. It does not matter if it was set by the browser's user-agent stylesheet or an authored stylesheet or what units it was set in. You can simply look up its computed value.
What use case is that not sufficient for? What kind of nightmare page are you styling where code you don't control is dynamically changing the root font size? Why do you need its exact computed value at all? The whole point of REMs is to style based on relative proportions to the text size e.g. when text is size X, buttons should have x padding on top/bottom and 2x on the sides. If the user sets their preferred font size to another value I do not care.
I use rems I don't love them but it's less worse unit we have. My point was more on grid being convoluted and media queries with arbitrary values like media (max-width: 32rem)
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
From my testing, as far as I've been able to tell it no longer has any impact on accessibility. The element itself does not appear in the tree, this makes sense display:contents is non-interactive. But all of the children correctly appear in the accessibility tree as if they did not have that shared parent element. But I am by no means an expert at operating screen readers, do you know of any specific issues with it?
The issue is if you do want the element to appear in the tree. If the element has semantic meaning it can mess things up.
Adrian Roselli is an accessibility expert who has done extensive testing and written up his findings: https://adrianroselli.com/2022/07/its-mid-2022-and-browsers-...
Yeah, though I find in practice I use `display: contents` far more than I do subgrid. Contents effectively deletes the node for layout purposes, but it still participates in the CSS cascade so you can use it in selectors, even `:hover` works when a child gets hovered, or use it as the origin for inheritable properties.
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.
I'd use <table>. It literally is a table. And for mobile just do a media query to turn it into a flexbox.
Yeah the claim that tables are hard to style for such a simple design doesn't really hold up in my opinion.
This took two seconds to make https://codesandbox.io/p/sandbox/5ry4rl
I do agree though that subgrid makes the HTML more readable though so I'm all for it.
The pricing UI example is exactly the type of thing I had to build a few years ago. Deceptively simple, two tables for comparison, but the rows need to line up.
Impossible without subgrid, either you need to have fixed heights or calculate heights with JS, but neither is elegant or simple, especially if you have react components and adhere to modular design, and you need to have those components agree on sizing.
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
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)
Try to select a tr / td without pulling your hair.
> A layout grid is not a table
Ain't it? Rows and columns get you a table.
A table is for tabulating data. They have quite different meaning and purpose, even if they share a couple of characteristics.
Tabulate means to organize by rows and columns.
Layout grids organize data by rows and columns.
They don't! Layout grids are less about the rows and columns and more about the lines separating them (which is why those get a lot of attention in CSS grid). Take a look at how layout grids are used in design and you will quickly find examples that are extremely inconvenient to realize with HTML tables. I'm sure it can be done and I'm sure some poor email marketing dev had to, but the result would be entirely static and not able to reflow.
You have just restated the similarity I referred to. The ways they are different make them important enough to distinguish.
“Tabulate” doesn’t just mean organising anything by rows and columns, it means organising data for a particular purpose. And layout grids usually end up looking quite different to tables because although they have a broadly similar underlying structure, the purpose is quite different.
HTML spec couldn’t just have added a grid element?
CSS grids are for presentation, HTML is for semantics. Ideally they are separated. That's why the use of <center> tag is deprecated.
As far as I know <b> and <i> is not deprecated at all. It’s just not recommended for 95% of the use cases.
They're not quite deprecated, but they're also not quite not deprecated at all:
> Historically, the <b> element was meant to make text boldface. Styling information has been deprecated since HTML4, so the meaning of the <b> element has been changed.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
I think CSS grid is too powerful to be represented in markup. I rotated the idea in my head for a bit but the most I could come up was elements that covered a small subset of CSS grid and which completely lost the entire appeal of being able to handle tracks dynamically.
This is a classic problem I identify across a wide variety of types of software. I call it "forcing a graph into a tree" and it comes up any time you have something that must be evaluated across multiple axises but the earliest assumptions (now invalidated) about the data restricted it to a tree, or the most really available tools to process it is with tree-like data structures and algorithms.
HTML is a tree. It's really great at trees. But defining a grid layout sometimes requires organizing data by both the rows and the columns. That can't fit into a tree.
I think a lot of people's complaints that "CSS is too complex, why can't we just do this in HTML" would go away if they could understand that CSS--being a rules-based system--can process the graph, but HTML can only ever define a tree. There are things that will just never work in just HTML.
This gets hard because trees are easy for people to understand. We have lots of examples of them: file systems (if you ignore symlinks). Family trees (if you ignore inbreeding). Tree of life taxonomies (if you ignore more than basic undergrad biology). You can probably guess by my caveats how much I feel it is important to study graphs. But graphs are "scary Computer Science" stuff to a lot of people, so they don't take the time to learn.
How would that have been responsive?
A table is a grid, but a grid does not have to be a table
Yes. I built layouts like this with automatic server-rendered tables 25 years ago, and they just worked with very little effort.
Tables weren't responsive or accessible or any of the other things we now recognize as essential, but it has certainly taken a long time to reinvent the table wheel. And all the while we've had to listen to people screaming in our ears that tables were bad, while also listening to them argue about which of their incredibly difficult and patently subpar "solutions" we were supposed to use instead.
<table> was a problem because it described content, not style. There's nothing wrong with creating grids.
Was going to say this too!
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.
Screen readers do care. A lot. Grid and subgrid solve the problem without breaking DOM and semantics, which is a huge concern in accessibility.
Random grid gotcha that drove me crazy some time ago: due to browser bugs we can't use <img> elements with percentage widths or heights as grid items. The grid cell dimensions get blown out to the ones of the original image. Seen in both Firefox and Chromium. Relevant FF bug is probably https://bugzilla.mozilla.org/show_bug.cgi?id=1857365 '<img> grid item with percentage height, "width: auto", "grid-template-columns: auto", and no track stretching makes column to have the same width of the original image's width' (although someone there claims it works in Chromium).
so if the img has a specific size set in width and height attributes or via css, and that size is not percentile or auto, the problem doesn't exist?
I'm just confused by the "original image's width".
The Firefox bug report has an image that illustrates the issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1857365#c0
not OP but (unless silently edited) they wrote
> "<img> elements with percentage widths or heights"
This sounds useful, but the example of the feature rows reminds me how sad it is that CSS sometimes requires adding information about the document structure to make a layout work. In this case the number of rows.
Ideally, we would have a way to align elements even when they don't share a parent. Or maybe a flex container that can have its layout mimic another flex container so the distribution in them can line up. It seems that there are a lot of heuristics and edge cases though to keep a simple DX.
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.
Yes, the syntax takes a while to get used to; they were attempting to cover several different use cases.
You can use ASCII art to “draw” your layout if you want to, which is quite accessible [1].
[1]: “Grid: how grid-template-areas offer a visual solution for your code” — https://webkit.org/blog/17620/grid-how-grid-template-areas-o...
Layout Land [1] is a great set of videos that explains CSS Grid
[1]: https://m.youtube.com/layoutland
Why does it need explaining, when it has to be self explaining and not some overcomplicated mishmash. Like someone was under the influence of psychedelics when working out the specifics.
We had to wait 15 years for proper positioning in css. Same shit repeated again.
It's quite straightforward to find the discussions that lead to the specs, if you're interested in participating.
So it went thru multiple people and they all said in unison: well, this is all ironed out, easy to use and looks ok. We did a great job!
Just mind boggling. I get it, maybe they want to create extra jobs, by adding complexity, hence more people are required for a role, but why keeping up the illusion? Fucking alter the economic systems if this was the goal.
I simply ignore it and use flexbox without any issues.
I think Flexbox is so much worse than CSS Grid. If Flexbox makes sense to you, it I don't think it should be that hard to learn CSS Grid, you'll already have many of the properties you need to understood learned. Grid just works properly in 2 whole dimensions where Flexbox sort of gives up after 1 and a half dimensions.
I know grid. It doesn’t do what I want, so I don’t generally use it.
I sympathize with your comment and imagine the overflowing downvotes as soon you openly critic the web/css/javascript and their people doing the standard. I watched tons of videos and read a lot on mdn about css grid, I don't touch it for a while I need to go back at it again... After tables/floats/abs positioning eventually convoluted flex we should have stopped and review what the heck people were doing on w3c, it's artificial complexity we don't deserve that
So we are back to grids after all the years put into css? We had this with html many years ago
This makes the content responsive way easier than any HTML grid could.
Yes but now they cascade for even more fun bugs whilst styling your layout :D
/s
I never found it comfortable to work with grids. The syntax and layout just feel off. Flexbox is a much more flexible and easy thing to work with.
There's plenty of overlap, but they solve different problems: flexbox when the content should control element sizing/fit, grid when the container should control element sizing/fit.
Another way to think about it: flexbox is for alignment of boxes in one dimension: horizontally or vertically.
CSS Grid is for two dimensional layout of rows and columns.
Back in the day, developers wanted page layout instead of the hacks on top of hacks with table-based layouts, floats and positioning to create layouts.
We’ve had CSS Grid designed for page layout on the web, in all browsers since 2017; as of 2022, only 12% of the top 1 million websites used CSS Grid, which to me is ridiculously low.
I use flexbox for grid purposes, simply because the syntax is straightforward and easy to read. Yeah, it’s one dimension, but if you nest it, it becomes two with no issues.
With nested flexbox the nested dimensions are not aligned to each other. With grid the items are aligned across both each row AND each column. With subgrid even nested grids can be aligned across nesting levels.
True. But so far I haven't faced layouts that I could not implement using flexbox.
I think the grid syntax is really off-putting - it’s one of the few places of “typical” CSS I tend to avoid unless something really calls for it. In my experience, it feels like the people most familiar with grid display, the syntax, and using it, are more on the design side than the programming side - most of my frontend peers who use it tend to misuse it when flex would work fine and be less rigid for their goals
But flex grow and align stretch exist, which moves control back to the parent...
A grid really feels like a list flexes to me too, functionally.
I agree. I occasionally turn to them to see if they work in a new setting, but find they never expose the features of a grid I would find useful. Everything must be manually placed, rather than allowing content to intelligently snap to multiple axes. Possibly I never have grasped some fundamental concept, possibly they are not suited to the sorts of layouts I usually work on. But more and more I feel they are designed to fulfil some purpose orthogonal to what I would need them to do.
I also find it much simpler to make responsive designs with flexbox than with grid.
Sounds like a source of bugs. Basically this means the grids can be nested to no end. It breaks locality in that now I have to understand what the parent would do before I can make sense of a component.
Why do you put styles in the code playground HTML and CSS file? I was staring at the first subgrid example’s CSS file for ages trying to figure how anything special was applied to the ul element.
it's because the CSS file is for styles not important to the example
Ah yes, a new css concept! I love this kind of article that invariably contains this kind of statement:
> This is mind-bending stuff, but it becomes intuitive with a bit of practice.
The problem is not the language, it's just that you did not spend enough time to learn it the proper way.
Have we reached the point where we can fully simulate quirks mode table behavior?
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.
If you nest two grids, the rows and columns of two sibling grids are not forced two align.
With subgrid the rows and columns of two sibling grids are aligned with each other by glueing them to the rows and columns of the parent grid.
Am I the only one who sees "content boxes"/divs with content displayed in different widths as poor design? At least in the example given, I would think you would want the image and its associated content box to be the same size for all four and not have its content vary in width based on how much content it has.
But in terms of functionality, I'm sure there are plenty applications for this!
is grid intended to replace flex at some point or live side by side
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?
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.
There were back in CSS 2 display values for table, table cell, table row etc which meant you could make divs or other block elements layout like tables did. Of course it wasn't supported in a certain browser with 90% market share.
> Grid doesn't have it's own element like table does, so you have to use css to apply that display to a div.
Well, OOTB, yeah. I personally like to make use of custom html elements a lot of the time for such things. Such as <main-header> <main-footer> <main-content> <content-header> etc, and apply css styles to those, rather than putting in classes onto divs. Feels a lot more ergonomic to me. Also gives more meaningful markup in the html. (and forces me to name the actual tags so I use much less unnecessary ones)
One of the many things I hate about React: can't easily create custom elements that truly exist in the DOM so I can style them in CSS.
Recent React round-trips custom elements better now. You just have to remember the standard's rule that all custom elements need to be named with dash (-) inside them.
It's more like a comic book, you define the layout and the elements slot into that. You can define how many rows and columns your comic has and then you can make some panels fit exactly into one spot, or you can have panels that span more than one row or column. So it's more of a 2d design system.
https://l-wortley0811-dp.blogspot.com/2010/10/comic-layoutsj...
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
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.
Live side by side unfortunately. I personally however always use grid, flexbox sucks.
On the other hand, I only use flexbox and I think grid sucks.
Flexbox is great for stacking and distributing elements vertically or horizontally, especially when you don't know how many there are.
Can you get the same alignment properties with the grid? If so, I will use the grid more often.
From the example:
I swear you that I had less hard time reading x86 assembly code or even c++ templates. I mean what the hell? Then if you go look at another example:> @media (max-width: 32rem)
I know what rem means, I just don't know what the hell MAY mean, that alone in a big project will make you hate your job as sometimes it's more easier predicting what the response of an LLM may be than what styling an element will have on a live page
[Edit] I'm not confusing rem with em, em are even worse, but still hard predicting what a rem might be, before arguing we shouldn't I'd like to stress out we should once it's used like that "@media (max-width: 32rem)"
[Edit2] Instead of just downvoting why don't you reply with your counter arguments? I really am interested in hearing what you have to say
Grid is a DSL certainly, but it's a very useful DSL to learn. I'd even argue that people skip Flexbox or forget everything they (think they) know about Flexbox and just learn CSS Grid.
One of the first callouts in the article is a suggestion to read the same site's interactive guide to CSS Grid if you aren't familiar with it: https://www.joshwcomeau.com/css/interactive-guide-to-grid/
> I'm not confusing rem with em, em are even worse, but still hard predicting what a rem might be, before arguing we shouldn't I'd like to stress out we should once it's used like that "@media (max-width: 32rem)"
`rem` is "just" the root Em, the em in the root font size (the font size of the `<html>` tag itself). In most browsers, with no `<html style="font-size: X;">` override (or `:root { font-size: X; }` stylesheet) that defaults to 16px.
In the Bootstrap 3/4-era responsive breakpoints you often see something like `@media (max-width: 512px) {}` to mean "mobile width". The reasons to migrate those sort of breakpoints to `rem` units instead include 1) adapts to custom browser settings (a user may set their default font size larger, for instance, for visual acuity reasons, which can be a useful accessibility desire), 2) adapts in some situations to zoom settings (browsers are allowed to style the website at a higher zoom as if the user had chosen an equivalent larger base font size), and 3) in the "retina screen" world where resolutions on a phone screen may be higher than desktop resolutions despite smaller screen size, using "roughly 32 `M` characters wide" is a better intuition than "exactly 512px wide" (and mobile browsers can lie a bit less about their pixel widths to meet your breakpoint assumptions).
You can back-of-the-envelope math `X rem * 16 px/rem` to get a pixel approximation if you need one, and that estimate will hold in a lot of cases in a majority of browsers, but leaves the browser more flexibility in adapting to adapting to user desires and hardware quirks than raw pixel counts.
thanks for the lesson, not needed because i know how to do a multiplication, but oh well people need to flex their domain knowledge. You're missing the whole point: drid dsl is overengineered and convoluted with browser behaving differently on some cases. Css is a disease
Put me on a C++/asm project and I'd have a hard time making heads or tails of it. So what? Your comment comes off as very angry without any meaningful critique of the article's central topic other than you had a hard time understanding it.
1rem is equal to the same number of pixels anywhere on a given page and, generally speaking, across pages on a given site. If you don't know what the value is it only takes a minute to find out. If you're writing CSS that'll be used on unknown pages, you either a) shouldn't care and just scale relative to whatever root font size the consumer set or b) should set your own size/scale, at build time or with custom properties. REMs have been around and standard practice for 10 years.
> 1rem is equal to the same number of pixels anywhere on a given page and, generally speaking, across pages on a given site.
That's not true, first of all the root font size might not be immediate to query and find out what it is, second it might change because of variables on the root or base font size might be percentage/rem based itself not necessarily in pixels and finally setting it in pixels doesn't take into consideration zoom levels, or OS-level font settings.
> REMs have been around and standard practice for 10 years.
I know but thanks for flexing it out, in fact I'm arguing that css is and has been bad for many years
My point was that there is only one root font size on a given page and it's trivial to find out what that is by looking in dev tools. It does not matter if it was set by the browser's user-agent stylesheet or an authored stylesheet or what units it was set in. You can simply look up its computed value.
What use case is that not sufficient for? What kind of nightmare page are you styling where code you don't control is dynamically changing the root font size? Why do you need its exact computed value at all? The whole point of REMs is to style based on relative proportions to the text size e.g. when text is size X, buttons should have x padding on top/bottom and 2x on the sides. If the user sets their preferred font size to another value I do not care.
I use rems I don't love them but it's less worse unit we have. My point was more on grid being convoluted and media queries with arbitrary values like media (max-width: 32rem)