Hacker News Reader

Comment by jzimdars | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com