Comment by MostExtremeCake | Hacker News Reader

Comment by MostExtremeCake | Hacker News Reader

MostExtremeCake

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.

Reply on news.ycombinator.com