Live data from Hacker News

Full-Bleed Layout Using CSS Grid

joshwcomeau.com

21–30 of 277 posts

Re: Full-Bleed Layout Using CSS Grid

#21
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

CSS is declarative and not imperative. A lot of people have issues with a different kind of programming. Also the "cascading" nature of CSS makes it hard to reason about.

The differences in how different engines/platforms behave definitely does not help when doing any non-trivial layout.

Re: Full-Bleed Layout Using CSS Grid

#23
post #10

> It's relatively easy to constrain all children, but CSS doesn't really have a mechanism to selectively constrain some children. Yes it does. You can use .wrapper h1, .wrapper p {} or soon .wrapper :is(h1,p) {} Alternatively, you can also use .wrapper > :not(.full-bleed) {} And in SCSS (or similar) you can write .wrapper { h1,p {} } (edit: Earlier versions of this comment mentioned :has instead of :is)

:has is not supported in any browser, and that seems unlikely to change, for performance reasons. https://caniuse.com/css-has

Re: Full-Bleed Layout Using CSS Grid

#24
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 it's because of the combinatorics of it and it's compounded by the specificity system, the size of the vocabulary, and no built-in compiler.

The combinatorics are tough for our lizard brains to reason out. If you don't have a strict set of rules for your CSS then you end up with a mixture of element rules, class rules, and id rules, and the combinations of these can get hard to hold in your head. Having compound styles doesn't help at all because it's easy to not realize you're setting a style accidentally.

Then what happens when there's a collision? The specificity system is supposed to sort that out, but without learning the rules there's just no way to intuit them. When I'm struggling with getting something just right and some library CSS is overriding my local CSS it's always the specificity rules that are at fault.

The vocabulary size is enormous. It's unclear exactly how many properties there actually are, but the most authoritative answer I could find was 522. That's a crazy number. And yes, that treats `margin` and `margin-left` as two separate properties, but they're still in there. By comparison there are 53 reserved words in Java and only 33 in Javascript. It's possible for a mere mortal to memorize these.

And finally there's no built-in compiler. Yes, I know about Sass, but that's not much more than a macro system; a useful macro system, but still just a macro system. A lot of us use compilers as our grammar and vocabulary checkers. If I do mis-spell a word in Java the compiler usually errors out and I'm forced to fix it. But if you mis-spell a property in CSS it's happy to just ignore it and you spend several minutes trying to figure out why your change did nothing.

Re: Full-Bleed Layout Using CSS Grid

#26
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

For me I think CSS is hard to understand mostly because the underlying concepts are low level and designed to accommodate ALL POSSIBLE rendering scenarios, not just "I'm putting a website on this laptop or phone screen".

CSS is able to target print and all manner of other different scenarios and needs. It's inherently complicated because it's very flexible and accounts for all kinds of use cases.

The problem is you don't need all that power most of the time, but it's there. To understand CSS you have to understand a lot of underlying concepts about layout and web page structure. People feel like "Why do I have to remember all these arbitrary rules?!". I sympathize - and sure a fair few things are arbitrary and never changed due to not breaking existing code - but most of the rules are not arbitrary, they just serve a bigger world than what we might be dealing with as web devs.

In the end I prefer to think of CSS as a powerful programming language that gives me lots of _primitives_, not a framework with a bunch of out of the box behavior that matches my narrow needs. If you want those, they are out there of course.

But yeah. CSS is hard and it takes study, practice, and time to be good at it. I think half of the time we struggle with CSS it's because we expect that it is "easy" and that it should cooperate without us investing time in learning it. It's written in short lines that look like plain English. It should do what we expect all the time, right?

Re: Full-Bleed Layout Using CSS Grid

#27
post #17
post #10

> It's relatively easy to constrain all children, but CSS doesn't really have a mechanism to selectively constrain some children. Yes it does. You can use .wrapper h1, .wrapper p {} or soon .wrapper :is(h1,p) {} Alternatively, you can also use .wrapper > :not(.full-bleed) {} And in SCSS (or similar) you can write .wrapper { h1,p {} } (edit: Earlier versions of this comment mentioned :has instead of :is)

I think the point being made was it's not easy to selectively have some children break out of a parent container with a max-width.

[deleted]

Re: Full-Bleed Layout Using CSS Grid

#29
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 CSS" searches and the resulting stylesheets are hobbled together messes.

If you learn the box model, if you learn the reasons behind selector specificity, and how cascading works, you'll really earn a true appreciation for CSS. It does not take long to learn, you just have to spend a day reading through the "boring" stuff.

Re: Full-Bleed Layout Using CSS Grid

#30
I really hated this era before flexbox and co. CSS used to be the least intuitive thing on the planet yet a lot of people claimed otherwise. We had to resort to silly tricks (remember overflow hidden?) in order to make up for the mess that CSS used to be. Again what really pissed me off isn't CSS inherent issues but the fact that many people claimed there was absolutely nothing wrong with it, a pattern I often see with many developers about this or that language. Obviously, there were some problems or we wouldn't be needing CSS grids or flexbox today.

I don't understand this.

You can appreciate something while still acknowledging its obvious flaws, nothing is perfect.

Post reply on HN