@ultimatedelman I suppose using a class that refers to the appearance of an element does stray slightly further away from "seperation of concerns", but whether that writes off this technique completely depends on the context and your priorities. I've done things this way before, because realistically we know we have control of the markup and can change the class to .h3 or .h4 at any point if needed (probably quicker than moving a selector from one part of the css to another - although either is a non-event really), and what we gain is a piece of clean and maintainable CSS (as opposed to having potentially hundreds of classes being explicitly stated). Obviously this wouldn't work for say a hosted ecommerce platform that needs to be user styleable, but that's what I'm saying about the context determining whether or not this approach will work. Either way we know the semantics of the elements themselves are correct, and IMO that's more important than the classes applied to it.
@ultimatedelman I suppose using a class that refers to the appearance of an element does stray slightly further away from "seperation of concerns", but whether that writes off this technique completely depends on the context and your priorities. I've done things this way before, because realistically we know we have control of the markup and can change the class to .h3 or .h4 at any point if needed (probably quicker than moving a selector from one part of the css to another - although either is a non-event really), and what we gain is a piece of clean and maintainable CSS (as opposed to having potentially hundreds of classes being explicitly stated). Obviously this wouldn't work for say a hosted ecommerce platform that needs to be user styleable, but that's what I'm saying about the context determining whether or not this approach will work. Either way we know the semantics of the elements themselves are correct, and IMO that's more important than the classes applied to it.