3 ms·

>Classes should therefore describe what something is, not how it's supposed to be presented. That's what we used to think when Semantic CSS was the big buzzwor

>Classes should therefore describe what something is, not how it's supposed to be presented. That's what we used to think when Semantic CSS was the big buzzword, lots of articles from '08-'11 preached it as the gospel. Turns out when a language is based on customizing presentation, presentation is semantic. > I had a number of locations that I highlighted with a blue background and rounded corners. I called it `location` since it highlighted each of the locations > When I opened the online store, I had a list of products and wanted to highlight each product using the same design pattern. Problem was, they weren’t locations. They were products. 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 design function was, of course, to highlight something. That was what I should’ve called it! https://snook.ca/archives/html_and_css/semantic-css https://snook.ca/archives/html_and_css/semantic-css

yellowapple 9y ago
> 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).
- SippinLean 9y ago
  Nope, he just removes the `highlight` class. >Except HTML (especially HTML5) is not based on "customizing presentation" Right, I meant CSS, and the HTML classes you use to support it. h1.highlight is just as semantic as h1. >CSS is the language that is based on customizing presentation Right, so your CSS should be based on class names that point to their design function. Not "what something is".
  - yellowapple 9y ago
    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".
    - SippinLean 9y ago
      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.

yellowapple 9y ago

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

SippinLean 9y ago
Nope, he just removes the `highlight` class. >Except HTML (especially HTML5) is not based on "customizing presentation" Right, I meant CSS, and the HTML classes you use to support it. h1.highlight is just as semantic as h1. >CSS is the language that is based on customizing presentation Right, so your CSS should be based on class names that point to their design function. Not "what something is".
- yellowapple 9y ago
  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".
  - SippinLean 9y ago
    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.