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.

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.

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

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.

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

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)

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.

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.

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.

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

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

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

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

Layout Land [1] is a great set of videos that explains CSS Grid

[1]: https://m.youtube.com/layoutland

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

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.