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.
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 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.
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 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?
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.
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.
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.
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.
17 comments
[ 5.0 ms ] story [ 80.5 ms ] threadWhat the author is describing is like a shorthand for style attributes.
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.
> (These days most of my microclasses are tied to SASS variables or mixins.)
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).
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?
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: 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. but also not too abstract, e.g.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: 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.