[lsdafjklsd]

The no nesting thing is huge! We refactored a lot of CSS earlier this year and that was one of the biggest pain points. Coupling the structure of your template to your CSS makes changing things very painful. Nesting also creates ambiguous classes that have no obvious connection, consider the following:

.my-component {

    .header {
 
        ...
  
    }  

}

You would just see header floating around in the markup, unsure of where it's namespaced.

Also I disagree that you shouldn't modularize your CSS. We now create a CSS file who's name corresponds with the class name.

/styles

  /components
  
    my-component.css

and in the markup

<div class=".MyComponent-wrap">

  <div class=".MyComponent-title">  
    ...  

  </div>  

</div>

With CSS like that you always know where a style is declared, and the order of the classes do not matter.

More on the issue: http://nicolasgallagher.com/about-html-semantics-front-end-a...

[marrs]

I tend to avoid nesting as well now.

Wrt your modularisation, that seems like a reasonable approach, although where do rules go if you have nested components?

From my experience, modularity really starts to bite when you also have inheritance.

For a simple case, you have a module A that contains class rules that are used as prototypes for rules in other modules. You want to modify behaviour. Where do you modify it, in the prototype or in the subtype? The answer isn't always obvious and sometimes 2 conflicting answers can be correct depending on the metaphor used for deciding how to modularise.

That's a simple case. A complex could be one where module A extends class rules from module B and module B extends class rules from module A. What happens when two rules extend each other? I've seen this in action, by the way. The SASS compiled without error so one presumes that there is a limit put on the recursion.