Hacker News Reader

Hacker News

Comment by captainbland | Hacker News Reader

Full thread

captainbland

"I could ask my mailman to guess what background-color: blue does and he’d probably guess right"

Mind you, ask your mailman what

"div.a > .b:nth-child(3n+2) { margin: -5px -1px -5px -10px; }"

is supposed to do and you might get a different response.

View on HN

And then looking at it the other way, the equivalent JS is:

    backgroundColor: "blue"

which as an isolated bit of code is no more or less understandable than the CSS.

The problem I've had with CSS is answering the question, "If I change this code, what will happen?" It is so easy for the answer to be "random other things break" that keeping CSS organised is really hard. At least with CSS-in-TS a "Find all references" will tell you where the style is used.

You can organize using a class hierarchy, which make it possible to have separate rules for .foo button and .bar button. To over-rule something you make it more specific like .foo form button, .bar form button

I think the core of the problem is that CSS is applied to the whole page, so it makes thinking about local changes hard.

CSS Modules[1] tries to help by introducing "local" CSS, then there are other approaches like BEM[2] that bake a namespace system into the class names, then there's OOCSS[3] that tries to break it down into separate .foo and .bar "objects" a bit like your example, then others going in the opposite direction like Atomic CSS[4] that try to make all the CSS rules so narrow that it is OK that they are global, then have multiple class names used on each HTML element to make the usage local.

Really, it is quite hard, lots of smart people trying to make it work.

Personally I've found the approach of CSS-in-TypeScript the easiest to work with, since I'm very familiar with TypeScript and it allow re-using the same tools to solve different problems (and my usecase wouldn't be a good fit for static HTML in the first place, so depending on JS for rendering is OK), but I can see how people not familiar with TypeScript might prefer a different approach to handling the complexity.

[1] https://medium.com/front-end-developers/css-modules-solving-... [2] http://getbem.com/introduction/ [3] https://www.keycdn.com/blog/oocss [4] https://acss.io/

> If I change this code, what will happen?

This is why I love single file Vue components[1] with scoped CSS/SASS. The styling for the component in question is right there with the markup and JS, and you know it's not effecting any other HTML with it's declared classes/styling. Breeds a lot of confidence when making changes without having to follow more rigid and fragile paradigms.

Obviously you will still have global styles and themeing but figured this is at least worth a mention.

1 - https://vuejs.org/v2/guide/single-file-components.html

Given proper class names, that's a more complex example but not ridiculous. If you asked what:

    .products > .widget:nth-child(3n+2) { margin: -5px -1px -5px -10px; }

someone would probably be able to say that it has something to do with adding margins to widgets, and maybe even that it only applies to some of them.

It does seem like a bit of a cherry picked example. However, for the most part, I think it's great how intuitive CSS naming conventions are. I think it's relatively easy to learn enough CSS to be dangerous.

Interesting, because the mailman would probably also be correct on that one, which is that it is crap code

Reply on news.ycombinator.com