Live data from Hacker News

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

blog.12spokes.com

11–18 of 18 posts

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

#11
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

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

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

#12

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 elemen…

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?

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

#13

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 elemen…

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.

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

#14

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 elemen…

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

instead of writing obtuse HTML:

    
you could continue to write semantic HTML:

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

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

#15
post #14

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 elemen…

I think the author failed to mention how this ties in with SASS/LESS mixins: instead of writing obtuse HTML: you could continue to write semantic HTML: 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 t…

Essentially, a CSS DSL.
Post reply on HN