
Why I love “describing in the browser” with OOCSS-Inspired Microclasses - 12spokes
http://blog.12spokes.com/web-design-development/describing-in-the-browser-with-oocss-inspired-microclasses/
======
jessedhillon
Wow. You're doing it wrong. You might as well use inline styling at this rate
and dump stylesheets altogether.

If, tomorrow, you decide that all tooltips need to change their style the
amount of work you have to do is O(N) in the number of tooltip elements you
have, whereas if you did this correctly, you would only need to change
.tooltip

In general, your CSS classes should relate to the semantic meaning of an
element -- .important, .aside, .help -- and not the visual presentation of an
element -- .blue, .padded etc. If all important elements need to change from
blue to orange, it's easier if their class is .important (one change) and not
.blue (where either you modify all important elements or you define .blue as
being orange-colored).

~~~
lhorie
I think the author failed to mention how this ties in with SASS/LESS mixins:

instead of writing obtuse HTML:

    
    
        <div class="corner-box brand-color-bg pad-box-mini shadow-box light-text-color content-box"></div>
    

you could continue to write semantic HTML:

    
    
        <div class="sign-up-callout"></div>
    

and then use mixins to separate the description of styling concepts and the
implementation details:

    
    
        /*implementation details*/
        .corner-box {...}
        .brand-color-bg {...}
    
        /*style descriptions*/
        .sign-up-callout {
           .corner-box;
           .brand-color-bg;
        }
    

I suppose the downside of the approach is that you need to carefully maintain
a dictionary that isn't too tied to implementation, e.g.

    
    
        .red {color:red;}
    

but also not too abstract, e.g.

    
    
        .box-callout {...}
        .box-call-to-action {...}

~~~
politician
Essentially, a CSS DSL.

------
andybak
This is massively mixing presentation with content. I know that doesn't matter
to some (many?) people but I wonder if a compromise could be found with
building up classes with SASS mixins that keeps your markup clean but gets
some of the maintainability benefits of this approach?

Also - let's have the debate about the _practical_ drawbacks people are likely
to discover when they use lots of presentational classes in their markup.

~~~
duncans
I think he's saying he does that at the end of the article:

> (These days most of my microclasses are tied to SASS variables or mixins.)

------
rcsorensen
This is a great example of CSS becoming programming.

With preprocessors (mentioned at the end of the article), prototyping can
finish with an element like

    
    
      <form class="content-box last mid-bg corner-box border-box bevel-box-light pad-box">
      ...
      </form>
    

then turn back to your application.less, throw in:

    
    
      .username-form {
        .content-box;
        .last;
        .mid-bg;
        .corner-box;
        .border-box;
        .bevel-box-light;
        .pad-box;
      }
    

and we're suddenly working with higher-level concepts in CSS, specifically
_not_ the basics of the style attributes.

Working this way gives you room to play with in-browser prototyping in a
strong way, using just the inspector and classes on elements to build up your
visuals.

------
the_gipsy
Content should be separeted from presentation: css class names and ids, which
are HTML attributes, should not be named after what types of content they
mark, not how it should look like.

What the author is describing is like a shorthand for style attributes.

------
kevinhamer
This isn't even a valid example of DRYness; you're repeating yourself in your
markup heavily to avoid it in your CSS. I hate to imagine <a href="..."
class="body-link brand-color-link hover-underline undecorated-link">...</a>
every time I want to make a link.

------
dsego
There was a similar article not so long ago about OOCSS + Sass.
[http://ianstormtaylor.com/oocss-plus-sass-is-the-best-way-
to...](http://ianstormtaylor.com/oocss-plus-sass-is-the-best-way-to-css/)

------
jinfiesto
I've moved in this direction also, and have found it's easier to maintain code
this way. The one caveat I've noticed is that sometimes if you're working with
two similar design elements and add a class to one, you have to go and
remember to add the same class to the other. It's really not a big deal and it
doesn't happen a ton, but it's enough to be mildly annoying.

------
epascarello
Working with jQuery UI that does this same thing is super painful and adds so
much page weight when you see the same class over and over again. Using a
SASS/Less solution would simplify it.

------
fourstar
This is not a win at all. I used to do this, until I realized that when I want
to change something I have to edit all my template files.

