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