> Being the lazy developer I was, though, I just reused the `location` class and applied it to my products. Clearly not ideal (but hey, it worked)!
The new problem, though, is that in this case, if the developer wants to eventually use a different style for locations v. products, he'll now have to do the thing he was trying to avoid in the first place and have to create the new style.
If he stuck to letting HTML describe the content and CSS describe the presentation of that content, then when his tastes inevitably change, he'd just need to change one or the other class' styles in his CSS and call it a day.
This is even more relevant if you're using some kind of CSS preprocessor language (or whatever the term would be) like SASS/SCSS or LESS, since you can define that style as a mixin and apply it to each of the styles for specific content classes as you see fit.
Of course, what he did can still be compatible with HTML being content-declarative if you use a class like "important" or "special" or something; that way, you're still describing what the thing is without polluting HTML with presentation details. You can likely even mix that together ("important product" or "important location"), which would then pave the way for having unimportant products/locations.
> Turns out when a language is based on customizing presentation
Except HTML (especially HTML5) is not based on "customizing presentation". HTML is based on describing documents and the contents thereof. There were a few violations of that principle once upon a time (<b>, <i>, <u>, <blink>, <marquee>, etc.), but these are vestigial at worst (and outright eradicated at best), leaving a language that really is meant to declaratively describe content.
CSS is the language that is based on customizing presentation, and always has been (and hopefully always will be, though I can't wait for the day when CSS becomes Turing-complete).
I think you have things backwards. CSS is meant to support HTML, not the other way around. Given that, the "CSS" class names (really HTML; classes have uses beyond stylesheets) absolutely should reflect "what something is".
That's a overly broad statement that doesn't reflect the more specific one I made. Your HTML should be rock-solid and use semantic tags, regardless of CSS. The presentational classes you add to it are there, partly, to support your CSS.
>the "CSS" class names absolutely should reflect "what something is"
The example and article above goes to show exactly why that's wrong, if their function is design, they should reflect their design function. This is not theoretical, it is based on practice.
> The presentational classes you add to it are there, partly, to support your CSS.
Again: you have things backwards. Classes are there to describe what an HTML element is supposed to represent. CSS uses these to decide how that thing is to be displayed. JavaScript uses these to decide how that thing is to behave.
> The example and article above goes to show exactly why that's wrong
Except they don't, as I already explained.
> if their function is design, they should reflect their design function.
Yes, and the design function of an HTML element class is to describe what that element is. The fact that CSS is able to make use of them is a side effect of that.
If you really want to abuse HTML semantics, then go ahead; nobody's stopping you. Just don't pretend that it's the correct approach.
> This is not theoretical, it is based on practice
And the standard practice is a tangled mess of <div class="grid grid-3-7 highlight">. Doesn't mean the standard practice is actually good, or that there's no room for improvement.
>CSS uses these to decide how that thing is to be displayed.
I already agreed with you: "they should reflect their design function"
You seem to be conflating semantic classes with presentational ones:
If all your articles have a blue border, maybe it makes sense to have .article have a border property. If your events, articles, and recipes all share the same Card format, it makes better since to keep those styles in .card.
>Except they don't, as I already explained.
You didn't explain; I said just remove the `highlight` class.
>Doesn't mean the standard practice is actually good, or that there's no room for improvement.
Not on its own, but the fact that this arose out of the maintenance nightmare that was "semantic CSS" from 5 years ago explains why it is now a best practice.
The new problem, though, is that in this case, if the developer wants to eventually use a different style for locations v. products, he'll now have to do the thing he was trying to avoid in the first place and have to create the new style.
If he stuck to letting HTML describe the content and CSS describe the presentation of that content, then when his tastes inevitably change, he'd just need to change one or the other class' styles in his CSS and call it a day.
This is even more relevant if you're using some kind of CSS preprocessor language (or whatever the term would be) like SASS/SCSS or LESS, since you can define that style as a mixin and apply it to each of the styles for specific content classes as you see fit.
Of course, what he did can still be compatible with HTML being content-declarative if you use a class like "important" or "special" or something; that way, you're still describing what the thing is without polluting HTML with presentation details. You can likely even mix that together ("important product" or "important location"), which would then pave the way for having unimportant products/locations.
> Turns out when a language is based on customizing presentation
Except HTML (especially HTML5) is not based on "customizing presentation". HTML is based on describing documents and the contents thereof. There were a few violations of that principle once upon a time (<b>, <i>, <u>, <blink>, <marquee>, etc.), but these are vestigial at worst (and outright eradicated at best), leaving a language that really is meant to declaratively describe content.
CSS is the language that is based on customizing presentation, and always has been (and hopefully always will be, though I can't wait for the day when CSS becomes Turing-complete).