7 ms·

Scalable and Modular Architecture for CSS

76 points by jcsalterego 15y ago

judofyr 15y ago
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 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)!
- intranation 15y ago
  Snook is quite well-known in front-end circles. He's been blogging for ages, and does indeed work on Y! Mail.
  - judofyr 15y ago
    That makes it even more important to put the name before the introduction.
- snookca 15y ago
  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.
latchkey 15y ago
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.
- mattmanser 15y ago
  99% of people do write JavaScript without using CoffeeScript you plonker!
- judofyr 15y ago
  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.
  - bobfunk 15y ago
    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.
  - jwdunne 15y ago
    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.
- snookca 15y ago
  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).
yycom 15y ago
on one page, please
skrebbel 15y ago
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.
- snookca 15y ago
  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.
  - skrebbel 15y ago
    Hm, cool. That shuts me up :-) Guess my underbelly feeling may simply be wrong then :)
misterbwong 15y ago
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.

76 points by jcsalterego 15y ago

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 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)!

intranation 15y ago
Snook is quite well-known in front-end circles. He's been blogging for ages, and does indeed work on Y! Mail.
- judofyr 15y ago
  That makes it even more important to put the name before the introduction.
snookca 15y ago
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.

latchkey 15y ago

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.

mattmanser 15y ago
99% of people do write JavaScript without using CoffeeScript you plonker!
judofyr 15y ago
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.
- bobfunk 15y ago
  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.
- jwdunne 15y ago
  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.
snookca 15y ago
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).

yycom 15y ago

on one page, please

skrebbel 15y ago

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.

snookca 15y ago
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.
- skrebbel 15y ago
  Hm, cool. That shuts me up :-) Guess my underbelly feeling may simply be wrong then :)

misterbwong 15y ago

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.