Scalable and Modular Architecture for CSS

I totally agree with the concept, but I think you need to work a little more on the presentation:<p>It's not obvious that Base, Layout, Modules and State are separate articles when you've already defined them under Four Types. I assumed the links in the ToC were anchor links (I was on an Android). You also define Module before Layout in Four Types.<p>You need to do something about the flow between the chapters. First of all: A big link to the next chapter at the bottom. Some of the chapters also ended a little abruptly (e.g. Applicability). Even though the chapters are quite small, it's still important to have <i>some</i> kind of "conclusion". It could be just one or two sentences, but you need to show that "I'm finished with this topic for now".<p>I'd love to see more examples about different of modules. What modules do you almost always need in a project? When do you split one module into two? How small can a module be? How big?<p>This seems very similar to OOCSS: <a href="http://www.slideshare.net/stubbornella/object-oriented-css" rel="nofollow">http://www.slideshare.net/stubbornella/object-oriented-css</a>. I can't find the right presentation right now, but Stubbornella had a great slide where she showed how often the Media-module is used in Facebook (it's everywhere!) and how much code was reduced by introducing it. That would be a great example for you too :-)<p>Did you really work on Yahoo! Mail? Well, don't wait until chapter 2 to say it! I have no idea who you even <i>are</i> in the introduction. I mean, your name is only in the footer. Move your name to be a part of the title and tell what proper projects you've been working on (so I know I can trust you)!

There are some pretty good tips in this article. Here's one I particularly liked from the Modules section:<p><i>Only include a selector that includes semantics.</i> A span or div holds none. A heading has some. A class defined on an element has plenty. [...] The more semantically generic the HTML element (like a span or div), the more likely it will create a conflict down the road. Elements with greater semantics like headings are more likely to appear by themselves within a container and you're more likely able to use an element selector successfully.

I'd be more impressed if this tutorial had included examples where you use SASS (or your favorite css compiler) for building out css. Simply because it provides you with proper organization of css rules and negates the need for naming conventions to figure out what things are. Using CSS without SASS is like writing JavaScript without using CoffeeScript.

Feels very tailored to classic websites. I have the underbelly feeling that for web applications with non-standard interactions (i.e. not just forms and buttons), you'd need more categories, or maybe different practices and rules governing these categories.

on one page, please