
CSS: Taking control of the cascade - joshuacc
http://37signals.com/svn/posts/3003-css-taking-control-of-the-cascade
======
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>)

~~~
jzimdars
_> 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.

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

~~~
jzimdars
_> 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.

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

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

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

~~~
kylemathews
Some details would be nice.

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

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

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

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

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

~~~
jzimdars
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 :)

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

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

