Hacker News Reader

Comment by enkrs | Hacker News Reader

Great article. While CSS grid is very powerful, maybe I'm not seeing the full picture in the examples: aren't the examples possible with just p { margin: 0 auto; max-width: 65ch } ? What does grid bring here?

View on HN

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.

Still not sure I get it. CSS makes it very easy to carve-out elements because of selector specificity.

    .content * { max-width: 65ch; margin: 0 auto; }
    .content img { max-width: 100%; width: 100%; }

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 :/

This might be solved by putting the margin on .content and using negative space for full-bleed elements, as in:

  .content { width: 65ch; margin: 0 auto }
  .content .full-bleed {
    width: 100vw;
    margin-left: calc((65ch - 100vw) / 2);
  }

yeah, that's the most common way of doing it afaik

Indeed the grid based solution in the article depends on selector specificity in exactly the same way as this.

You would get a ragged left margin if you have elements less than 65ch wide.

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.

you actually wouldn't, as these smaller elements still get centered by the auto margin

Use a negative margin on the full bleed item? Bit hacky, but works fine:

  .content {
    max-width: 85ch;
    width: 100%;
    margin: 0 auto;
  }
  .content img,
  .content .full-bleed {
    width: 100vw;
    height: auto;
    padding-left: 50%;
    margin-left: -50vw;
  }

Then use something like `#content > :not(.full-bleed) { .. }`

only theoretically, for the p element itself.

ch is a fontsize relative unit and this solution wouldn't provide the same results for any element that has another text sizing and is not wrapped within a p tag.

and if you apply these rules to the whole content wrapper, you loose the ability to have some children selectively fill the viewport.

Reply on news.ycombinator.com