2 ms·

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

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.

yellowapple 9y ago
> 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.
- SippinLean 9y ago
  >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.

yellowapple 9y ago

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

SippinLean 9y ago
>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.