I think part of it is that there are probably lots of additional items that you want to constrain to the main column, so your CSS would end up looking more like:
#content p, h1, h2, h3, nav { .. }
Kind of a pain to manually specify each element that you want to constrain, when it's most of them. This approach allows you to instead target the items that you don't want to constrain.
Additionally, as a more specific issue, the static-site generator that I use renders markdown such that images are inside a paragraph, so your approach wouldn't work at all for me.
Edit: As an aside, that's a super fun site! Lots of neat little UI easter eggs.
It's a neat demo of CSS Grid, for sure, but the above would be my much preferred way of doing this kind of layout. Maybe if there were a need for elements (quotes, callouts, etc.) in the side columns alongside the content, then it makes more sense to use Grid.
i think your version will break a bunch of common uses of `margin-{left,right}`; e.g. indenting like
blockquote {
margin-left: 15px;
/* ... */
}
won't work properly (it'll go all the way to the left). i haven't checked, but i think that in the grid version, you'd get an indent as expected.
and i think that's the grid version's main advantage – it doesn't "use up" `margin` and `max-width`, so you're free to use them to style stuff that appears in the body. feels a bit more composable, though at the cost of also feeling massively overcomplicated :/
I left out some assumptions for brevity, but my presumption was that everything inside of the container (like p tags) would be display: block, so it would try to fill the max-width of 65ch with blank space anyway.
Additionally, as a more specific issue, the static-site generator that I use renders markdown such that images are inside a paragraph, so your approach wouldn't work at all for me.
Edit: As an aside, that's a super fun site! Lots of neat little UI easter eggs.