New layouts with CSS Subgrid
joshwcomeau.com
joshwcomeau.com
ul { display: contents }
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.
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.
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.
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-...
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.
You're killing it, Josh. Thank you for writing and teaching us.
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.
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)
Ain't it? Rows and columns get you a table.
Layout grids organize data by rows and columns.
“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.
> 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/...
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.
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'm just confused by the "original image's width".
> "<img> elements with percentage widths or heights"
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.
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...
We had to wait 15 years for proper positioning in css. Same shit repeated again.
/s
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.
A grid really feels like a list flexes to me too, functionally.
> 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.
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.
But in terms of functionality, I'm sure there are plenty applications for this!
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.
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)
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
https://l-wortley0811-dp.blogspot.com/2010/10/comic-layoutsj...
.grid {
display: grid;
grid-template-columns: 35% 1fr 1fr 1fr;
}
.grid header {
grid-row: 1 / 3;
}
.grid ul {
grid-row: span 2;
grid-column: span 3;
display: grid;
grid-template-rows: subgrid;
grid-template-columns: subgrid;
}
> @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
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.
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
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.
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.