Why I love “describing in the browser” with OOCSS-Inspired Microclasses | Hacker News Reader

Why I love “describing in the browser” with OOCSS-Inspired Microclasses

blog.12spokes.com

22 points12spokes15 comments

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

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 {...}

Essentially, a CSS DSL.

I often find myself repeating similar styling between semantic elements. I know that I could factor the common rules together but it never seems to quite work out that way. LESS/SASS gives us an opportunity to use both approaches together i.e. you first define your microstyles and then mix those into your semantic styles. I've never been comfortable with the stylesheets I produce when trying to follow the purely semantic approach, they always seem to end up a mess. Hopefully building up styles using 2 layers of abstraction(micro/semantic) will help to bring some clarity to my stylesheets.

I concur with the the majority - I smelled something fishy the second I saw design elements in the HTML. Structure and style are separate for a reason.

Now the question is, can we redirect the enthusiasm the author has for this workflow? Is there a better way to 'describe' and design at the same time while writing maintainable HTML?

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.

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

This. Sass mixins give you the modular benefits of micro-classes but without polluting your HTML.

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.

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.

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.

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

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.

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.

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.

Reply on news.ycombinator.com