top | item 46047053

New layouts with CSS Subgrid

309 points| joshwcomeau | 3 months ago |joshwcomeau.com

98 comments

order

webstrand|3 months ago

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

    ul { display: contents }
it's more efficient, if you don't need subgrid features, but still want the nested element structure for other reasons.

moron4hire|3 months ago

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.

Izkata|3 months ago

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.

dsego|3 months ago

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.

echelon|3 months ago

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.

paulhebert|3 months ago

Agreed. I’m happy to be on his mailing list. I’m always excited for a new Josh article

Nathanba|3 months ago

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

webstrand|3 months ago

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.

N_Lens|3 months ago

Have we wrapped all the way around to <table> layouts again?

sussmannbaka|3 months ago

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)

dreamcompiler|3 months ago

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.

halapro|3 months ago

<table> was a problem because it described content, not style. There's nothing wrong with creating grids.

hackthemack|3 months ago

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.

buovjaga|3 months ago

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).

bryanrasmussen|3 months ago

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".

flowerthoughts|3 months ago

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.

dsego|3 months ago

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.

lofaszvanitt|3 months ago

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.

alwillis|3 months ago

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...

hexasquid|3 months ago

It's quite straightforward to find the discussions that lead to the specs, if you're interested in participating.

herpdyderp|3 months ago

I simply ignore it and use flexbox without any issues.

hollowturtle|3 months ago

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

Surac|3 months ago

So we are back to grids after all the years put into css? We had this with html many years ago

system2|3 months ago

This makes the content responsive way easier than any HTML grid could.

moi2388|3 months ago

Yes but now they cascade for even more fun bugs whilst styling your layout :D

/s

rckt|3 months ago

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.

code_biologist|3 months ago

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.

sings|3 months ago

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.

herpdyderp|3 months ago

I also find it much simpler to make responsive designs with flexbox than with grid.

another_twist|3 months ago

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.

herpdyderp|3 months ago

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.

ambigious7777|3 months ago

it's because the CSS file is for styles not important to the example

HenriTEL|3 months ago

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.

scotty79|3 months ago

Have we reached the point where we can fully simulate quirks mode table behavior?

kumarvvr|3 months ago

How is this different to, and better than using nested grids?

psolidgold|3 months ago

This is addressed in the article. This really shines when you have sibling dependent layouts.

laszlokorte|3 months ago

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.

kafkaesque|3 months ago

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!

t1234s|3 months ago

is grid intended to replace flex at some point or live side by side

SquareWheel|3 months ago

They're complimentary. As a general (though not exclusive) rule, consider flex for one-dimensional layouts, and grids for two-dimensional layouts.

Brajeshwar|3 months ago

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.

moi2388|3 months ago

Live side by side unfortunately. I personally however always use grid, flexbox sucks.

hollowturtle|3 months ago

From the example:

  .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;
  }
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

WorldMaker|3 months ago

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.

joestrouth1|3 months ago

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.