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).
instead of writing obtuse HTML:
<div class="corner-box brand-color-bg pad-box-mini shadow-box light-text-color content-box"></div>
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?
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.)
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">
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.
What the author is describing is like a shorthand for style attributes.