6 ms·

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 di

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.

leksak 6y ago
You could probably write an article that'd be very often read if you teach CSS from this perspective.
- akersten 6y ago
  I've wanted to actually! It's become almost a meme that CSS is hard and a badge of honor to be ignorant of it, but it's not that bad. I will concede that there are some annoying design decisions (like margin collapsing) but overall, I think it's a well-designed and evolving solution that has stood the test of time. That we've been able to so easily add things like flexbox and Grid to it in response to the changing needs of the web is kind of a testament of how well CSS modelled the problem of layout. Learning box-model and cascading will let one solve 90% of common CSS problems people encounter just from first principles.
commandlinefan 6y ago
> 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.
- deleted 6y ago
  [deleted]
- daveilers 6y ago
  Which editions did you read? Many of the css options that make complex layouts more palatable have only been commonly supported more recently. (flex-box:2015 , grid:2017, newer units:2010)
  - commandlinefan 6y ago
    I don't remember the specific editions, but it was a long time ago - long before flex-box and grid were around. Still, back then, people could work magic with CSS using floats and positioning and such, and I couldn't make any sense of it. Maybe it's time to pick up a more up-to-date book on CSS and try again with the modern timesavers.
- akersten 6y ago
  I don't know if there is a single perfect resource out there, but the thing that helped me the most was understanding CSS as a shift from programming with an imperative mindset to a declarative mindset. Treat CSS as a medium for expressing 'what you want' instead of 'what to do.' My guiding principle is that "less is more" and if you find yourself writing a ton of super-specific and messy CSS, it's one of two scenarios: there's an easier way to do it, or you have a very picky project manager who wants things to be pixel-perfect to the mock-up. If it's the latter, you have my sympathies. Focusing on the box model is important because it sets the right overall mindset for working with CSS layout. At the risk of being too patronizing, I would highly encourage everyone to at least read the MDN article on CSS basics[0] just to set a baseline for CSS terminology, the idea of the box model, and a few other things. You should then read more detailed documentation [1] on the box model and start to get a feel for how it works in depth. Most pedestrian "spacing issues" should be solved at the level of adjusting margins and padding. The other arm I mentioned was specificity, and this tends to be where a lot of folks get caught asking why their rules aren't applying and those sorts of issues. The documentation is fairly 'academic' but worth a read-through[2]. MDN overall is a great resource for a motivated learner, but unfortunately I don't have any 'CSS the right way' sorts of articles in my hat at the moment. Maybe others will post some. [0]: https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/CSS_basics https://developer.mozilla.org/en-US/docs/Learn/Getting_start... [1]: https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/The_box_model https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_... [2]: https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
hombre_fatal 6y ago
> I think CSS is "difficult to understand" because most people who do front-end don't want to spend a day learning it. Yeah, "html/css" is the object of our derision on HN as some sort of thing that's beneath us. As if someone who is an "html/css" designer isn't a real developer. Yet at the same time we complain that we have to learn it. That after pretending it was trivial all this time, we're annoyed that we can't just fake our way through it when the going gets tough. But the other reason it's hard is that UI and clientdev is hard. There's this weird meme that UI is just bells and whistles and stakeholder pleasers instead of a human interface that demands a lot of forethought and expertise, and something that has to be functional and possibly even a joy for the user to use. You can see this when people here brag about being backend developers that never touch the client as if that's something to brag about.
aarpmcgee 6y ago
I've been writing CSS for about 10 years at nearly every professional job I've had. I don't get 'stuck' often and generally feel competent, but I am far from an expert or a master. I think CSS is difficult to understand because there are so many ways to accomplish a task, and so many of those ways lead to (sometimes) unforeseeable consequences, and nearly all of the APIs (possibly with the exception of css grid) don't feel very coherent... in my experience. I think it is difficult to learn because there's no real apparent holistic design to really grok. I tried mdgriffith's elm-ui on a personal project and it was a breath of fresh air. It felt like an utterly excellent abstraction and I hope someone ports it to Typescript/React/JSX some day.
- bobthepanda 6y ago
  it also doesn't help that sometimes you have to whack-a-mole different browser implementations of the spec, and particularly if you're working on a bit of a website somebody else owns you have to be very careful about specificity, what styles other teams may be using, etc.
- jacurtis 6y ago
  Yeah I think working with CSS is like working with Databases. There are a lot of ways in databases to get the job done. At first glance it seems to work the way you want and even survives early testing or even deployment. It doesnt fall apart until much later when you are trying to build upon it, scale it, etc.. This causes many people to learn the wrong way to do something because they might not stick around until it falls apart. The next time they have to do something they remember the way they got it to work last time and do it again, never realizing they are leaving a trail of tears for future developers to clean up the mess with. CSS is very much the same way. I can't tell you how many times I have seen CSS files that are a house of cards. One wrong element gets added into a markup and the whole thing crumbles. Unnecessary use of !important, wildcards, overly specific, not specific enough, inconsistent media queries, desktop-first layouts (as opposed to mobile-first, or often times a mixture of the two depending on the element), and so on. At first glance, the stakes for bad CSS also seem pretty low (which is not the case with databases or backend code). This further causes developers to just hack at it until it works or is "close enough". It instills bad habits that last years or even entire careers.
rimliu 6y ago
Yes, this exactly. Spend no time trying to understand something and then claim that something is hard to understand. No, sir, throwing stuff at the wall and hoping some will stick is not a good way to learn. Alas, this approach is becoming more and more prevalent with everything, not just CSS.
CGamesPlay 6y ago
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.
wruza 6y ago
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.
- akersten 6y ago
  CSS is a top-down language, not a constraint language. It is not surprising that you cannot construct things in the same way as you would in a constraint-based layout system. I am sure I could discover an equal "simple" example that is easy in CSS but difficult/impossible in GTK. That you cannot use a hammer in the same way as a crowbar, even though they are both blunt instruments, is not a condemnation of the hammer. So yes, you do need to evaluate what the right tool for the job is - like JS to do a quick width-match on the labels' natural widths - after the CSS did most of the rest. That is not "bla-bla-blah," that's just knowing the limits of your tools. The frustration seems to be the impression that CSS should be able to solve any conceivable layout desire on the web, which isn't its charge: CSS is first and foremost made to style web documents, which by-and-large don't fit as easily into the constraint-based-layout box as a traditional desktop app would. Since this kind of desire often crops up in desktop-like SPAs, where JS use is endemic already, it's not wrong to use a little bit more JS to nudge the visual experience a little closer to what you'd see on a desktop app. I guess my takeaway is, CSS doesn't promise the world, so if you come in expecting that, you'll walk away disappointed. Luckily there are many tools in the web dev toolkit to achieve your engineering desires, and it's not verboten to use them (aside from a philosophical desire to avoid JS, but if the biggest problem for your page when JS is disabled is that the labels are slightly different sizes, I think you're doing a great job already).
jagthebeetle 6y ago
While I think this is definitely a useful foundation, things get a lot more complicated quickly once you jump into a large site's stylesheet(s). Why isn't this element the size I specified? Or why is there a tiny amount of scroll overflow here when I specify overflow-x hidden? What does vertical-align do and how does it work when inline and inline-block boxes are in an inline flow? etc. etc. So I would add that the next frontier after learning the proposed foundations is learning how the browser actually determines box sizes and layout, and I think this is difficult to understand, mainly because it jumps straight into the spec, or worse, your browser's layout engine specifics. https://www.w3.org/TR/css-sizing-3/#auto-box-sizes https://www.w3.org/TR/css-sizing-3/#auto-box-sizes for instance is a nontrivial subsystem that a CSS dev will easily run into when nesting flex containers, and I think the standard box model of yore wasn't really written to help grok these concepts. Edit: one particularly hairy explanation from the spec I recently ran into while trying to deepen my understanding of the box model: "Except for table boxes, which are described in a later chapter, and replaced elements, a block-level box is also a block container box. A block container box either contains only block-level boxes or establishes an inline formatting context and thus contains only inline-level boxes. Not all block container boxes are block-level boxes: non-replaced inline blocks and non-replaced table cells are block containers but not block-level boxes. Block-level boxes that are also block containers are called block boxes." Not saying this is relevant for the average use case, but I believe even something like the box model is a day-to-learn-lifetime-to-master kind of thing.
fenomas 6y ago
> I think CSS is "difficult to understand" because most people who do front-end don't want to spend a day learning it. I couldn't disagree more. There are a ton of reasons CSS really is hard, even when one understands the box model etc. E.g.: 1. Hugely non-modular. An element's behavior always depends, to some extent, on styles applied to other elements. Systems full of entangled global state are inherently complex, separate from any other concern. 2. Highly magical. E.g. if you want to control how elements stack with z-index, you need to also know that z-index is ignored for elements that aren't positioned, which in turn means you need to set up your margins differently because positions disable margin collapsing. There's no one "model" to learn; it's a big morass of interconnected rules and edge cases. 3. Extremely fragile. Layout changes that a human user might consider minor often can't be done without significantly redesigning the page. Of course, problems like these can all be mitigated to various extents. But that takes care and experience; it's not just a matter of reading some articles like you imply.
lucasgelfond 6y ago
Where is the best place to learn CSS from a more foundational/complete perspective? I took freeCodeCamp's responsive web dev course but still find myself googling a lot of "how to do x in CSS"

leksak 6y ago

You could probably write an article that'd be very often read if you teach CSS from this perspective.

akersten 6y ago
I've wanted to actually! It's become almost a meme that CSS is hard and a badge of honor to be ignorant of it, but it's not that bad. I will concede that there are some annoying design decisions (like margin collapsing) but overall, I think it's a well-designed and evolving solution that has stood the test of time. That we've been able to so easily add things like flexbox and Grid to it in response to the changing needs of the web is kind of a testament of how well CSS modelled the problem of layout. Learning box-model and cascading will let one solve 90% of common CSS problems people encounter just from first principles.

commandlinefan 6y ago

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

deleted 6y ago
[deleted]
daveilers 6y ago
Which editions did you read? Many of the css options that make complex layouts more palatable have only been commonly supported more recently. (flex-box:2015 , grid:2017, newer units:2010)
- commandlinefan 6y ago
  I don't remember the specific editions, but it was a long time ago - long before flex-box and grid were around. Still, back then, people could work magic with CSS using floats and positioning and such, and I couldn't make any sense of it. Maybe it's time to pick up a more up-to-date book on CSS and try again with the modern timesavers.
akersten 6y ago
I don't know if there is a single perfect resource out there, but the thing that helped me the most was understanding CSS as a shift from programming with an imperative mindset to a declarative mindset. Treat CSS as a medium for expressing 'what you want' instead of 'what to do.' My guiding principle is that "less is more" and if you find yourself writing a ton of super-specific and messy CSS, it's one of two scenarios: there's an easier way to do it, or you have a very picky project manager who wants things to be pixel-perfect to the mock-up. If it's the latter, you have my sympathies. Focusing on the box model is important because it sets the right overall mindset for working with CSS layout. At the risk of being too patronizing, I would highly encourage everyone to at least read the MDN article on CSS basics[0] just to set a baseline for CSS terminology, the idea of the box model, and a few other things. You should then read more detailed documentation [1] on the box model and start to get a feel for how it works in depth. Most pedestrian "spacing issues" should be solved at the level of adjusting margins and padding. The other arm I mentioned was specificity, and this tends to be where a lot of folks get caught asking why their rules aren't applying and those sorts of issues. The documentation is fairly 'academic' but worth a read-through[2]. MDN overall is a great resource for a motivated learner, but unfortunately I don't have any 'CSS the right way' sorts of articles in my hat at the moment. Maybe others will post some. [0]: https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/CSS_basics https://developer.mozilla.org/en-US/docs/Learn/Getting_start... [1]: https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/The_box_model https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_... [2]: https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity

hombre_fatal 6y ago

> I think CSS is "difficult to understand" because most people who do front-end don't want to spend a day learning it. Yeah, "html/css" is the object of our derision on HN as some sort of thing that's beneath us. As if someone who is an "html/css" designer isn't a real developer. Yet at the same time we complain that we have to learn it. That after pretending it was trivial all this time, we're annoyed that we can't just fake our way through it when the going gets tough. But the other reason it's hard is that UI and clientdev is hard. There's this weird meme that UI is just bells and whistles and stakeholder pleasers instead of a human interface that demands a lot of forethought and expertise, and something that has to be functional and possibly even a joy for the user to use. You can see this when people here brag about being backend developers that never touch the client as if that's something to brag about.

aarpmcgee 6y ago

I've been writing CSS for about 10 years at nearly every professional job I've had. I don't get 'stuck' often and generally feel competent, but I am far from an expert or a master. I think CSS is difficult to understand because there are so many ways to accomplish a task, and so many of those ways lead to (sometimes) unforeseeable consequences, and nearly all of the APIs (possibly with the exception of css grid) don't feel very coherent... in my experience. I think it is difficult to learn because there's no real apparent holistic design to really grok. I tried mdgriffith's elm-ui on a personal project and it was a breath of fresh air. It felt like an utterly excellent abstraction and I hope someone ports it to Typescript/React/JSX some day.

bobthepanda 6y ago
it also doesn't help that sometimes you have to whack-a-mole different browser implementations of the spec, and particularly if you're working on a bit of a website somebody else owns you have to be very careful about specificity, what styles other teams may be using, etc.
jacurtis 6y ago
Yeah I think working with CSS is like working with Databases. There are a lot of ways in databases to get the job done. At first glance it seems to work the way you want and even survives early testing or even deployment. It doesnt fall apart until much later when you are trying to build upon it, scale it, etc.. This causes many people to learn the wrong way to do something because they might not stick around until it falls apart. The next time they have to do something they remember the way they got it to work last time and do it again, never realizing they are leaving a trail of tears for future developers to clean up the mess with. CSS is very much the same way. I can't tell you how many times I have seen CSS files that are a house of cards. One wrong element gets added into a markup and the whole thing crumbles. Unnecessary use of !important, wildcards, overly specific, not specific enough, inconsistent media queries, desktop-first layouts (as opposed to mobile-first, or often times a mixture of the two depending on the element), and so on. At first glance, the stakes for bad CSS also seem pretty low (which is not the case with databases or backend code). This further causes developers to just hack at it until it works or is "close enough". It instills bad habits that last years or even entire careers.

rimliu 6y ago

Yes, this exactly. Spend no time trying to understand something and then claim that something is hard to understand. No, sir, throwing stuff at the wall and hoping some will stick is not a good way to learn. Alas, this approach is becoming more and more prevalent with everything, not just CSS.

CGamesPlay 6y ago

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.

wruza 6y ago

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.

akersten 6y ago
CSS is a top-down language, not a constraint language. It is not surprising that you cannot construct things in the same way as you would in a constraint-based layout system. I am sure I could discover an equal "simple" example that is easy in CSS but difficult/impossible in GTK. That you cannot use a hammer in the same way as a crowbar, even though they are both blunt instruments, is not a condemnation of the hammer. So yes, you do need to evaluate what the right tool for the job is - like JS to do a quick width-match on the labels' natural widths - after the CSS did most of the rest. That is not "bla-bla-blah," that's just knowing the limits of your tools. The frustration seems to be the impression that CSS should be able to solve any conceivable layout desire on the web, which isn't its charge: CSS is first and foremost made to style web documents, which by-and-large don't fit as easily into the constraint-based-layout box as a traditional desktop app would. Since this kind of desire often crops up in desktop-like SPAs, where JS use is endemic already, it's not wrong to use a little bit more JS to nudge the visual experience a little closer to what you'd see on a desktop app. I guess my takeaway is, CSS doesn't promise the world, so if you come in expecting that, you'll walk away disappointed. Luckily there are many tools in the web dev toolkit to achieve your engineering desires, and it's not verboten to use them (aside from a philosophical desire to avoid JS, but if the biggest problem for your page when JS is disabled is that the labels are slightly different sizes, I think you're doing a great job already).

jagthebeetle 6y ago

While I think this is definitely a useful foundation, things get a lot more complicated quickly once you jump into a large site's stylesheet(s). Why isn't this element the size I specified? Or why is there a tiny amount of scroll overflow here when I specify overflow-x hidden? What does vertical-align do and how does it work when inline and inline-block boxes are in an inline flow? etc. etc. So I would add that the next frontier after learning the proposed foundations is learning how the browser actually determines box sizes and layout, and I think this is difficult to understand, mainly because it jumps straight into the spec, or worse, your browser's layout engine specifics. https://www.w3.org/TR/css-sizing-3/#auto-box-sizes https://www.w3.org/TR/css-sizing-3/#auto-box-sizes for instance is a nontrivial subsystem that a CSS dev will easily run into when nesting flex containers, and I think the standard box model of yore wasn't really written to help grok these concepts. Edit: one particularly hairy explanation from the spec I recently ran into while trying to deepen my understanding of the box model: "Except for table boxes, which are described in a later chapter, and replaced elements, a block-level box is also a block container box. A block container box either contains only block-level boxes or establishes an inline formatting context and thus contains only inline-level boxes. Not all block container boxes are block-level boxes: non-replaced inline blocks and non-replaced table cells are block containers but not block-level boxes. Block-level boxes that are also block containers are called block boxes." Not saying this is relevant for the average use case, but I believe even something like the box model is a day-to-learn-lifetime-to-master kind of thing.

fenomas 6y ago

> I think CSS is "difficult to understand" because most people who do front-end don't want to spend a day learning it. I couldn't disagree more. There are a ton of reasons CSS really is hard, even when one understands the box model etc. E.g.: 1. Hugely non-modular. An element's behavior always depends, to some extent, on styles applied to other elements. Systems full of entangled global state are inherently complex, separate from any other concern. 2. Highly magical. E.g. if you want to control how elements stack with z-index, you need to also know that z-index is ignored for elements that aren't positioned, which in turn means you need to set up your margins differently because positions disable margin collapsing. There's no one "model" to learn; it's a big morass of interconnected rules and edge cases. 3. Extremely fragile. Layout changes that a human user might consider minor often can't be done without significantly redesigning the page. Of course, problems like these can all be mitigated to various extents. But that takes care and experience; it's not just a matter of reading some articles like you imply.

lucasgelfond 6y ago

Where is the best place to learn CSS from a more foundational/complete perspective? I took freeCodeCamp's responsive web dev course but still find myself googling a lot of "how to do x in CSS"