Scalable and Modular Architecture for CSS | Hacker News Reader

Scalable and Modular Architecture for CSS

smacss.com

76 pointsjcsalterego16 comments

I totally agree with the concept, but I think you need to work a little more on the presentation:

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.

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

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?

This seems very similar to OOCSS: http://www.slideshare.net/stubbornella/object-oriented-css. 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 :-)

Did you really work on Yahoo! Mail? Well, don't wait until chapter 2 to say it! I have no idea who you even are 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)!

Snook is quite well-known in front-end circles. He's been blogging for ages, and does indeed work on Y! Mail.

That makes it even more important to put the name before the introduction.

Yes, very similar to OOCSS. One thing I'd like to do is talk about a number of frameworks and how they fit into these concepts. Nicole has the Facebook example on her web site, I believe.

I'll definitely work on the rest. All of your input is spot on, I think.

Thank you for the very thoughtful feedback.

There are some pretty good tips in this article. Here's one I particularly liked from the Modules section:

Only include a selector that includes semantics. 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.

99% of people do write JavaScript without using CoffeeScript you plonker!

SASS can be dangerous when it comes to nesting. It's so easy to just keep nesting rules, and before you know it you've coupled your CSS tightly to the structure on one specific page.

Couldn't agree more. I'm actually starting to become very skeptical of my own use of compass and sass.

SASS makes it extremely easy to generate loads of really complex selectors that are very tightly coupled to the HTML they are styling.

Mixins also makes it very easy to end up with badly bloated CSS. When a mixin defines a gradient and you apply it to different selectors, you'll get the whole bunch of browser prefixed gradient declarations repeated in lots of different places of your final css. A simple class with the gradient defined used in the HTML will make the final CSS much leaner.

Personally I've decided to limit my use of SASS/compass far more and follow a style much closer to what's described in this article.

Another thing is that, generally, the more nesting you add, the more inefficient the compiled CSS will be. Getting carried away with SASS-like nesting could very well produce a splodge of inefficient, single-use CSS.

I don't believe that SASS saves you from proper organization or naming convention. However, Less and SASS have been mentioned and I'll see about added something that covers how I believe those tools can fit into this (because I believe that can and do).

Very strongly disagree with this -- not because there's anything wrong with SASS, but because it introduces another thing that needs to be learned for many people. A good tutorial should be teaching one concept at a time, otherwise it is really confusing for people that aren't already familiar with both concepts (which is kind of the target audience for a tutorial).

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.

Actually, much of what I've detailed came as a result of my work on Yahoo! Mail and Calendar, which is a highly complex web application. Smaller "classic" sites can get away with not having as rigid of a system. Nicole Sullivan's OOCSS covers a bit about this component-based approach and Nicole formerly worked at Yahoo! and has done consulting for Facebook and other companies with large-scale web apps.

If you have any additional categorization that you think would be applicable, however, I'm open to feedback.

Hm, cool. That shuts me up :-)

Guess my underbelly feeling may simply be wrong then :)

on one page, please

Reply on news.ycombinator.com