

Scalable and Modular Architecture for CSS - jcsalterego
http://smacss.com/book/

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

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

~~~
judofyr
That makes it even more important to put the name _before_ the introduction.

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

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

~~~
judofyr
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
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.

------
skrebbel
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
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
Hm, cool. That shuts me up :-)

Guess my underbelly feeling may simply be wrong then :)

------
yycom
on one page, please

