Live data from Hacker News

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

blog.12spokes.com

1–10 of 18 posts

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

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

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

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

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

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

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

#5
post #4

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

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

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

#6
post #4

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

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

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

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

Post reply on HN