3 ms·

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

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

tammer 14y ago
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?
ollysb 14y ago
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.
lhorie 14y ago
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 14y ago
  Essentially, a CSS DSL.

tammer 14y ago

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?

ollysb 14y ago

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.

lhorie 14y ago

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 14y ago
Essentially, a CSS DSL.