CSS: Taking control of the cascade | Hacker News Reader

CSS: Taking control of the cascade

37signals.com

77 pointsjoshuacc20 comments

I'm not sure how much I agree with this approach. When you do what this article is describing, you are creating a very tight coupling of your css structure to your dom hierarchy. This can create a lot of issues when you are trying to refactor your code or getting new people on-boarded to the project.

These rules can get very confusing when someone tries to edit your HTML by adding classes to a new element they created, only to figure out that those classes don't add any styles in that particular context. Good stylesheets should have classes that have consistent behavior no matter where they are on the page.

That said, I think SCSS (and sass/less) is pretty nifty. The real heavy lifting they do, for me at least, comes from mixins and being able to programmatically create classes.

For an example, look at how the rainbow effect is created on this page: http://html5readiness.com (it's with a for loop in sass, technique is outlined in http://nimbupani.com/notes-from-html5-readiness-hacking.html)

> I'm not sure how much I agree with this approach. When you do what this article is describing, you are creating a very tight coupling of your css structure to your dom hierarchy. This can create a lot of issues when you are trying to refactor your code or getting new people on-boarded to the project.

We've found it to be just the opposite. Because nested selectors don't repeat the names of parent elements it's a piece of cake to grab a block and move it up or down in the tree or just plain move it somewhere else. We find that we refactor more because it's so much easier to hold the style model in your head and so clear where to move a block of styles in order to increase or decrease their scope. That just makes for better CSS.

I tend to chain selectors as little as possible in plain CSS, so I generally don't run into having to read huge chains of sub-selectors.

I will agree that heavily-cascaded stylesheets are practically impossible to read. Writing styles in a way that reduces your need to create long inheritance chains feels like a more flexible option (not so tightly dom-coupled) that doesn't require a "style model", though.

How do you handle adding the same styles to page elements that aren't siblings/exist in vastly different areas of the dom structure?

Mixins could probably do it, but writing too many of those would open up new problems.

> How do you handle adding the same styles to page elements that aren't siblings/exist in vastly different areas of the dom structure?

That's usually a case for refactoring. Either by pulling styles common to both elements out and up the tree so they apply more widely or creating a class that can modify both. In the latter case we'll usually use a technique like the last example in the article (more of an OOCSS approach) that works independent of the dom structure.

Makes sense. Do you ever run into specificity collisions when you pull styles out of the main style tree?

I could see whatever you pulled out being clobbered by the huge amount of specificity you have built up by mirroring the dom. Heavy use of the child selector would probably prevent that from happening as much, though.

It's difficult to explain without lengthy examples but we aren't seeing a lot of collisions (really none) because we're very careful to only nest when necessary and only as deeply as necessary. We aren't taking a stand here and completely obliterating cascading, we're just being mindful about when things really should flow to child element instead of just letting it happen all the time.

  > figure out that those classes don't add any styles
  > in that particular context

That's one way to learn that you don't add classes for styling. Just style the markup you have.

While this sounds really awesome and clean, "just styling the markup you have" can produce horrific results in dynamic design/presentation-heavy sites.

I've worked on a project which used a technique like this, but was not even as closely mirroring the DOM, and the end result was terrible. We ended up with specificity horrors which will best not be seen. Nobody wants to touch those stylesheets anymore.

did you use child selectors? did you use @extend?

Some details would be nice.

Well, multiple editors were at work. The approach described creates selectors that were generally more specific than they needed to be. Eventually, people needed something to be styled differently in a context that was already heavily specified. So they needed to have even more specific selectors to override an existing selector. As soon as someone stuck some ID in front of that whole selector (which is almost too easy using SASS/SCSS) it was basically game over.

I think OOCSS is an approach to help here, but once you have such a mess it is pretty hard to refactor.

God, when this OOCSS thing will be forgoten. It just moves mess to another place and instead of mess in CSS you get mess in CSS and HTML.

I guess you can create a mess either way. For me OOCSS was easy to scale out onto lots of elements and it was certainly easier to keep track of what is affecting what once you change something.

I wrote a little post response to the OP article showing the problems and what you should do to avoid them.

[CSS: Don’t take control of the Cascade, make love to it.](http://kuroir.com/post/10148994785/css-dont-take-control-of-...)

Hope you find it interesting.

This seems like a really interesting step toward HTML/CSS 'libraries' where you have reusable styles on reusable small chunks of DOM.

The to-do list example they use is a good one. You'll occasionally see jQuery used like this, to instantiate blobs of page in known configurations.

I don't know enough about, say, SproutCore or JS GUI libraries like it to know if any of them use this approach, but it seems like an obvious thing for them to do.

Or I may be overrating the approach. Still, sounds useful.

I do a lot of near-pixel-for-pixel reproduction from Photoshop documents, and I find that using rule nesting, mixins and child selectors (a similar style to the final example from the article, the first example is atrocious) definitely helps me build more semantic HTML.

Here is a quick cut-and-paste from a LESS stylesheet:

https://gist.github.com/1212027

There are a lot of random items and I find it easier not to cascade styles as much as some recommend. I try to consolidate styles into generic classes or mixins as I find opportunities to re-use them. I try not to use the child selector unnecessarily (the article uses it a totally unnecessary amount) because I often need to add unsemantic wrapper elements to achieve the right effect.

The examples in the article are simplifications for the purpose of illustrating the points. We'd almost never use nesting to any element all the way back to the HTML or BODY laments. But when you have elements like SECTION, ARTICLE, LI, DIV, etc which can be nested infinitely in HTML judicious use of the child selector is a godsend.

The examples in your gist would not benefit from additional use of child selectors, but I'll bet they'd appreciate it if the parent elements did :)

I'll be doing a talk in October covering this topic and front-end development in general at Magmarails.

I think this article is a step in a good direction whether or not you agree with it - main reason being that front-end development NEEDS more discussion. It's heavily undefined, and unrefined right now.

The alluded to arms-race reminds me of Nicole Sullivan's presentation about CSS best practices: http://news.ycombinator.com/item?id=2439420

A video of the presentation is the first response to the top comment.

Reply on news.ycombinator.com