Live data from Hacker News

Full-Bleed Layout Using CSS Grid

joshwcomeau.com

161–170 of 277 posts

Re: Full-Bleed Layout Using CSS Grid

#161
post #160

I implemented something like this on my website [1] and I'm not really sold on it and I'm considering changing back. The two things that I've lost are collapsing margins between paragraphs/headers and the ability for any asides (like a floating image or a footnote) to vertically span multiple paragraphs. For margins between paragraphs I replaced them with grid-gap, but always having the same grid-gap is not great; yo…

I recommended dropping vertical margin and instead using exclusively margin-bottom (or padding-bottom) as much as possible. The behavior is generally more intuitive, and you'll get the control you're looking for.

Re: Full-Bleed Layout Using CSS Grid

#162

Earlier quoted context omitted.

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 iss…

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,…

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

Re: Full-Bleed Layout Using CSS Grid

#164
> but CSS has an obscure unit that makes our life a little bit easier

I've been out of the HTML game for a while, is ch the new em? em has been around for a while.

I understand that they are slightly different, but is there a strong reason to use one over the other?

Re: Full-Bleed Layout Using CSS Grid

#165

Earlier quoted context omitted.

> most people who do front-end don't want to spend a day learning it. Can you link to some good resources? I've read "CSS The Definitive Guide" by Eric Meyer, "Eric Meyer on CSS" (also by Eric Meyer) and "CSS Zen Garden" and I still can't get CSS to do anything useful and always resort to table-based layouts because they work.

You sound a lot like me. I'll use CSS for colors/fonts/theming/separation and then do layout with tables :) . None of the stuff I work on is really all that complicated, so "tables are slow" just doesn't come up because the pages aren't large at all so 5ms vs 50ms doesn't matter.

Using tables for things that aren't tables is terrible for accessibility.

Re: Full-Bleed Layout Using CSS Grid

#166
post #13

It’s beyond me why CSS has to be so hard to understand. I have made several attempts and got it right, but it feels like I have to start at zero every time. I believe, it’s because CSS is not a programming language, but we are trying to do programming with it. Like: if screen is mobile then render divs stacked. I don’t know

I think CSS is "difficult to understand" because most people who do front-end don't want to spend a day learning it. Ask some people who make the claim it's difficult: what is the box model, and what is selector specificity. I can almost guarantee they won't be able to answer those questions, because they haven't bothered to actually try to learn CSS. Their knowledge of CSS is built from a set of "how do I do X in CS…

While I agree with the main thrust of this comment; I don't think I'll ever "earn a true appreciation for CSS". Even the most careful application of class naming guidelines eventually creeps into specificity battles, and you cannot predict exactly what a line of CSS will do until it's actually applied to an element.

However: it's unclear to me what a better solution would look like; and it's clear to me that nothing better would ever be so much better as to "beat" CSS.

Re: Full-Bleed Layout Using CSS Grid

#167
post #13

It’s beyond me why CSS has to be so hard to understand. I have made several attempts and got it right, but it feels like I have to start at zero every time. I believe, it’s because CSS is not a programming language, but we are trying to do programming with it. Like: if screen is mobile then render divs stacked. I don’t know

I think CSS is "difficult to understand" because most people who do front-end don't want to spend a day learning it. Ask some people who make the claim it's difficult: what is the box model, and what is selector specificity. I can almost guarantee they won't be able to answer those questions, because they haven't bothered to actually try to learn CSS. Their knowledge of CSS is built from a set of "how do I do X in CS…

Pardon me, but I've read tens of technical references, rationales and getting started's in my life, but not a single one was so ritualistic and/or useless for practicing as everything about css. The reason is...

Their knowledge of CSS is built from a set of "how do I do X in CSS" searches

Because "box model and selector specificity" is light years away from how to do X. If you want an analogy, you are suggesting to win a chess tournament by thoroughly learning chess rules and figures. But you can not. It is okay for chess, where you build up your expertise for years and decades, but not for a rapid application development. Css is a bike with no front wheel, one pedal and it only turns left, unless you know that sit-backwards hack. There are better (more reason-enabling at least) layout systems out there, but cool web guys are digging in their heels on that "css" thing. And that would be okay, iff they made that damn bike at least complete, at least once in its lifetime.

Want a simple, trivial puzzle?

  (component1)
    .form
      label.a input
      label.b input
  .some-content
  (component2)
    .form
      label.c input
Make all labels of the same, non-fixed width, for these forms to look more aligned under different label localisations. Without recomposing layout elements. In constraint-based layout, it is a.w = b.w = c.w (priority:low). In gtk, you add (a,b,c) into the same SizeGroup. In css I'm doing it the wrong way, these requirements are strange, I should rethink my model, take a different/better approach, maybe it is okay for them to not be aligned, because awesome css at least solves a huge load of problems and the internet rests on it, bla-bla-blah.

That even may have an almost-css-only solution, but whatever it is, it will be yet another "recipe" with a pile of crutches as ingredients. Which is likely not compatible with rendering loops or a structure of a half of popular js/css frameworks.

Re: Full-Bleed Layout Using CSS Grid

#168

I hate that people use CSS Grid like this. For some reason, I see so many people reach for CSS Grid like it's the de facto solution for responsive design. This is a bad design because you're tying the child elements to the grid layout of the parent. If you added an extra column in the grid, you'd have to go and adjust it for the full bleed elements. IMO a better solution would've been to just use a column layout with…

The parent-child problem you mention can be addressed with names. Children can say "grid-name: footer". This is just a hint for the parent to decide where to place it in the grid. Then the parent can use grid-template-areas to arrange its children. You no longer need to change the children if you're adding columns to the layout.

(I agree with you on this simple layout)

Re: Full-Bleed Layout Using CSS Grid

#169
post #164

> but CSS has an obscure unit that makes our life a little bit easier I've been out of the HTML game for a while, is ch the new em ? em has been around for a while. I understand that they are slightly different, but is there a strong reason to use one over the other?

ch is based on the width of a "0" character, em is based on the font size, which is the height of the character. for setting widths of things that contain text ch makes more sense. For padding, spacing, font sizes, inline symbols, and that kind of thing, em makes more sense.

Re: Full-Bleed Layout Using CSS Grid

#170
post #159
post #145

Earlier quoted context omitted.

Widespread flex gap support will probably eliminate 95% of grid usage in my apps today: https://caniuse.com/flexbox-gap And what a surprise, it's just Safari holding us back again. =_=

The new IE.

Very disingenuous of you. IE was a trashfire because it refused to do anything in a standard way, meaning it had to be specially catered for. Safari is slow to follow the standards but at least its compliant. A engine that isn't Chrome is very essential for keeping the web open, especially since Firefox user share keeps going down.
Post reply on HN