

Scalable and Maintainable CSS Approaches - cwebbdesign
http://cwebbdesign.tumblr.com/post/23666803241/scalable-and-maintainable-css-approaches

======
jasonrr
This is something I've been thinking a lot about recently, and while all of
these approaches solve some problems I think the requirement for maintainable
CSS is a fundamentally different approach to the purpose of CSS. Once you make
the mental switch from "CSS is the stuff that I do to make the things that I
build look right" to "CSS is a component of everything I build" it becomes
easier to see what I mean. It's not about "I need to be able to reuse this
font size" as much as it is "I want to reuse this widget when I am display
text in this way on any page".

In other words, if you want to build something maintainable, start thinking
about all the ways you can help people not write custom CSS at all.

Also, LESS and SASS at their core do little to help with this problem, and can
even hurt you with unintentional specificity (due to nesting) that hurts
reusability. Mixins help you think "reusability" but they can really easily be
misused in ways similar to how people are misusing CSS right now. This is by
no means an attack on LESS/SASS, which I love. It is just a reaction to
working on a large project that is making the switch and seeing the fallout.

~~~
lbotos
I'm not sure I follow. Are you advocating writing "classless" CSS? Could you
elaborate as to what you mean by "not write custom CSS"? I don't mean to be
pedantic but CSS of any kind is "custom". I think you are advocating OOCSS
techniques but trying to call them something else. (No offense)

~~~
jasonrr
I am saying that you can follow OOCSS coding practices and still wind up with
a ton of really great abstracted styles that you don't reuse. That is because
most people look at OOCSS and only see the "this is how you write proper CSS"
and don't realize that most of the work is around planning and communicating.
How many of the folks using OOCSS have a style guide of some kind that they
are sharing to let people know what exactly is available to be reused?

This article focused on the first part and even compares different approaches,
but misses the point that OOCSS is advocating a process overhaul, not just a
change to the way that you write CSS.

When I say help people not write custom CSS, I am referring to reuse. Writing
the code the right way is of course a pre-requisite, but from experience, not
nearly enough.

------
michaelbuckbee
The approaches laid out seem reasonable, but it's hard not to feel as if the
web dev community has moved on to using LESS and SASS as a means of addressing
some of the same issues.

~~~
philipwalton
These approaches are not incompatible with SASS/LESS. If anything, learning
them is more important now that we have preprocessors.

~~~
roryokane
If that's the case, I would be interested to see a tutorial on OOCSS that
assumes you're already using Sass, and skips explaining the parts of OOCSS
that Sass already solves. I hadn't really taken OOCSS seriously because I
thought Sass solved everything that OOCSS did.

~~~
philipwalton
What part of OOCSS do you think SASS already solves? Perhaps there's some
disagreement about this that can help me answer your question.

~~~
nilliams
I would assume (perhaps wrongly?) he's referring to mixins, which allow you to
easily re-use chunks of declarations (or objects). The pure OOCSS alternative
to this is to separate your classes more.

Quick example, OOCSS way of making the notion of 'fancifying a thing', is to
make a separate class to represent 'fanciness'.

    
    
      .fancy { color: hotpink; font-style: italic }
      .thing { width: 100px; height: 40px }
    

Then in your HTML apply both classes to make a fancy thing: <div class="thing
fancy">ta-da</div>

Whereas in SASS you could do that with a mixin instead:

    
    
      @mixin fancy { color: hotpink; font-style: italic }
      .fancy-thing { width: 100px; height: 40px; @include fancy }
    

And in your HTML, you then apply a single class: <div class="fancy-
thing">bam</div>

There are advantages of both, and there are clearly variations you could make
on the SASS version (i.e. you could make a separate _thing_ mixin too, then
mix both into a single fancy-thing class - making the _thing_ concept as
reusable as in the CSS version).

Personally I like the level of understanding that doing it the CSS way brings
(note this is also an example of the separating 'skin' from 'structure' idea,
which I think is very valuable). You could argue that it could lead to class-
itis though. Swings and roundabouts.

------
jacobr
I find that a combination of SMACSS and a lot of shared helper classes (left,
right, center, size-<n>, ...) really helps with maintainability.

I don't get the DRY CSS approach of wanting to avoid changing HTML. CSS
changes are much more expensive, as they can affect the design on unrelated
pages (especially if you don't write modular CSS), which means more testing.

And are there any real world use cases or benefits of "semantic class names"?
If not, and if you think they hurt maintainability, why would anyone advocate
them?

~~~
rimantas

      > And are there any real world use cases or benefits of
      > "semantic class names"?
    

Yes. Class names tell what the stuff is, CSS rules tell how to style it. Once
you see blue 14px text on the left which has class "red-12px-right" you are
enlightened.

~~~
jacobr
"Class names tell what the stuff is" is not a "real world use case or
benefit". In an HTML document, the defined vocabulary is the HTML elements and
some attributes. Class names are styling hooks, with the exception of
microdata.

'red-12px-right' is a stupid class name (and a strawman). A better example
would be 'heading-primary', instead of a "semantic" approach like '.news h2 {
}' (which could have the same styles as '.blogs h1' and '.members h3'...)

------
ilaksh
They invented a solution for scalable and maintainable UIs many, many years
ago. Its called a widget.

