6 ms·

I used to think this way until reading this article by Nicolas Gallagher: http://nicolasgallagher.com/about-html-semantics-front-end-architecture/ http://nicol

I used to think this way until reading this article by Nicolas Gallagher: http://nicolasgallagher.com/about-html-semantics-front-end-architecture/ http://nicolasgallagher.com/about-html-semantics-front-end-a... These days I'm quite convinced trying to author your markup such that you can redesign a site by applying a different stylesheet has the dependencies backwards. If you try to keep visual information out of your HTML, you end up authoring stylesheets designed to nimbly navigate your DOM structure to precisely target elements to style in a way that makes your CSS extremely coupled to the particular site you are building. Your HTML documents are already coupled to your project, so rather than writing CSS that's coupled to that HTML, I've found it to work much better to author CSS from a mindset that the CSS knows nothing about the document it's trying to style. This leads to writing what I call "library-style" CSS, where you are almost trying to build your own Bootstrap or similar; something that you could actually use on multiple projects if you wanted. A class like "download-book" is not very useful if you have multiple buttons in a project that are meant to look the same way and not all of them trigger a book download.

yoran 10y ago
I disagree. I find that SASS mixins provide the same reusability as classes but in a much cleaner way. True, it makes your HTML and CSS very coupled, but it does provide you with a true clean separation of content and presentation. I find // style.scss @mixin button($color, $size) { ... } .download-book { @include button( $color: red, $size: big ); } .send-email { @include button( $color: blue, $size: small ); } // index.html <button class="download-book">Download book</button> <button class="send-email">Send email</button> much cleaner than // style.scss .button { ... } .red { ... } .blue { ... } .big { ... } .small { ... } // index.html <button class="button big red">Download book</button> <button class="button small blue">Send email</button> 1. When you change the visual aspect of an element, you go to the stylesheet and don't go adding/removing classes from the content layer (HTML). 2. When using generic names like "button", "big", "small", etc... I always find myself in a naming conflict at some point. The likelihood of semantic names having conflicts is much smaller. Of course, your CSS file becomes a lot bigger. But when enabling compression, the stylesheets using mixins turn out to be smaller (see https://tech.bellycard.com/blog/sass-mixins-vs-extends-the-data/ https://tech.bellycard.com/blog/sass-mixins-vs-extends-the-d...). Also, your HTML file is likely smaller too when using semantic classes.
- jsnk 10y ago
  I agree with your point of view as well. With Vue, I am writing all my styles in a .vue file which contains a component composed of style, markup, and js. It's incredibly clean and easy to maintain. >> Of course, your CSS file becomes a lot bigger. If you use something like webpack and you start splitting code based on the page you are on, this problem goes away as well. I find that only place the 2nd case makes sense is if you are writing a CSS framework like Bootstrap. Otherwise, I find this way writing CSS increasingly rare.
- chucksmash 10y ago
  > 2. When using generic names like "button", "big", "small", etc... I always find myself in a naming conflict at some point. The likelihood of semantic names having conflicts is much smaller. css-modules[0] are a nice solution to this. Your nice, simple class names like "button" are transformed as part of build process to something less likely to collide, like "ltuZCYvCyDVU_2kG0Sspr": [0]: https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules
- always_good 10y ago
  I find tha the library-style "button" "red" "blue" "big" example prevents me from having to flip over and maintain CSS with every HTML change. Yet your first example has everyone editing CSS files and appending new classes to it all the time, which in my experience is the fastest way to end up with unmaintainable CSS. Mixins sounded good to me at first, but I've only experienced less maintainability when the CSS was too clever.
- sklivvz1971 10y ago
  A class called "download-book" wouldn't be semantic either. A semantic choice of classes should represent the roles that things have in the UI hierarchy: if a "book download" button is the main action of the page, it should have a class of, say "main-action", possibly with an extra "download" class to show UI specific to download actions. If a "book download" button is just an action, for example a button that is repeated multiple times in a table, then it needs a different class, like "action", still possibly with "download". This is exactly like properly written HTML is semantic, elements represent hierarchical roles ("nav", "footer"), not their look, nor their content.
jonahx 10y ago
Strongly disagree, and the primary reason is that semantic HTML makes your source and stylesheets readable and easy to navigate and change for that reason. That is, setting aside technical arguments about re-usability for a moment, it's disastrous to have to look at a large codebase in this style: <div class="red pull-left pb3"> <div class="grid row"> <div class="col-xs-4"> when you could look at this: <div class="basket"> <div class="product"> <div class="searchResults"> The latter, aside from sparing your brain endless visual noise, makes it instantly clear how the html maps to the page elements. Taken from http://maintainablecss.com/chapters/semantics/ http://maintainablecss.com/chapters/semantics/ > If you try to keep visual information out of your HTML, you end up authoring stylesheets designed to nimbly navigate your DOM structure to precisely target elements to style in a way that makes your CSS extremely coupled to the particular site you are building. As for this technical argument, it's flatly untrue. Writing semantic HTML and the coupling you are referring to are completely orthogonal as long as you are using a tool like Sass / postCSS / etc to author your CSS.
- mooseburger 10y ago
  Thing is, if you're using Angular (or most likely any of the hot SPA frameworks out there), you don't need semantic CSS class names, since the model bindings will make the meaning quite clear.
- nilliams 10y ago
  You're ignoring GPPs argument though, 'basket', 'product' and 'searchResults' aren't reusable. From the POV of a dev on your team (who knows the framework), I know how to change 'pull-left', 'row', 'col-xs-4' to get the result I want without CSS spelunking.
  - jonahx 10y ago
    My answer was implicit is the final comment. The purpose of those elements is not re-use. It's clarity. The re-use happens in the Sass (or other preprecessor) code. Somewhere in your Sass, you define "basket" as a "pull-left; row; col-xs-4" or even higher level constructs which you plan to re-use... that's up to you. The point is they are orthogonal issues. Creating re-usable chunks of CSS does not suddenly absolve you of the responsibility to make your HTML readable. You can do either one without the other, but you should be doing both.

yoran 10y ago

I disagree. I find that SASS mixins provide the same reusability as classes but in a much cleaner way. True, it makes your HTML and CSS very coupled, but it does provide you with a true clean separation of content and presentation. I find // style.scss @mixin button($color, $size) { ... } .download-book { @include button( $color: red, $size: big ); } .send-email { @include button( $color: blue, $size: small ); } // index.html <button class="download-book">Download book</button> <button class="send-email">Send email</button> much cleaner than // style.scss .button { ... } .red { ... } .blue { ... } .big { ... } .small { ... } // index.html <button class="button big red">Download book</button> <button class="button small blue">Send email</button> 1. When you change the visual aspect of an element, you go to the stylesheet and don't go adding/removing classes from the content layer (HTML). 2. When using generic names like "button", "big", "small", etc... I always find myself in a naming conflict at some point. The likelihood of semantic names having conflicts is much smaller. Of course, your CSS file becomes a lot bigger. But when enabling compression, the stylesheets using mixins turn out to be smaller (see https://tech.bellycard.com/blog/sass-mixins-vs-extends-the-data/ https://tech.bellycard.com/blog/sass-mixins-vs-extends-the-d...). Also, your HTML file is likely smaller too when using semantic classes.

jsnk 10y ago
I agree with your point of view as well. With Vue, I am writing all my styles in a .vue file which contains a component composed of style, markup, and js. It's incredibly clean and easy to maintain. >> Of course, your CSS file becomes a lot bigger. If you use something like webpack and you start splitting code based on the page you are on, this problem goes away as well. I find that only place the 2nd case makes sense is if you are writing a CSS framework like Bootstrap. Otherwise, I find this way writing CSS increasingly rare.
chucksmash 10y ago
> 2. When using generic names like "button", "big", "small", etc... I always find myself in a naming conflict at some point. The likelihood of semantic names having conflicts is much smaller. css-modules[0] are a nice solution to this. Your nice, simple class names like "button" are transformed as part of build process to something less likely to collide, like "ltuZCYvCyDVU_2kG0Sspr": [0]: https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules
always_good 10y ago
I find tha the library-style "button" "red" "blue" "big" example prevents me from having to flip over and maintain CSS with every HTML change. Yet your first example has everyone editing CSS files and appending new classes to it all the time, which in my experience is the fastest way to end up with unmaintainable CSS. Mixins sounded good to me at first, but I've only experienced less maintainability when the CSS was too clever.
sklivvz1971 10y ago
A class called "download-book" wouldn't be semantic either. A semantic choice of classes should represent the roles that things have in the UI hierarchy: if a "book download" button is the main action of the page, it should have a class of, say "main-action", possibly with an extra "download" class to show UI specific to download actions. If a "book download" button is just an action, for example a button that is repeated multiple times in a table, then it needs a different class, like "action", still possibly with "download". This is exactly like properly written HTML is semantic, elements represent hierarchical roles ("nav", "footer"), not their look, nor their content.

jonahx 10y ago

Strongly disagree, and the primary reason is that semantic HTML makes your source and stylesheets readable and easy to navigate and change for that reason. That is, setting aside technical arguments about re-usability for a moment, it's disastrous to have to look at a large codebase in this style: <div class="red pull-left pb3"> <div class="grid row"> <div class="col-xs-4"> when you could look at this: <div class="basket"> <div class="product"> <div class="searchResults"> The latter, aside from sparing your brain endless visual noise, makes it instantly clear how the html maps to the page elements. Taken from http://maintainablecss.com/chapters/semantics/ http://maintainablecss.com/chapters/semantics/ > If you try to keep visual information out of your HTML, you end up authoring stylesheets designed to nimbly navigate your DOM structure to precisely target elements to style in a way that makes your CSS extremely coupled to the particular site you are building. As for this technical argument, it's flatly untrue. Writing semantic HTML and the coupling you are referring to are completely orthogonal as long as you are using a tool like Sass / postCSS / etc to author your CSS.

mooseburger 10y ago
Thing is, if you're using Angular (or most likely any of the hot SPA frameworks out there), you don't need semantic CSS class names, since the model bindings will make the meaning quite clear.
nilliams 10y ago
You're ignoring GPPs argument though, 'basket', 'product' and 'searchResults' aren't reusable. From the POV of a dev on your team (who knows the framework), I know how to change 'pull-left', 'row', 'col-xs-4' to get the result I want without CSS spelunking.
- jonahx 10y ago
  My answer was implicit is the final comment. The purpose of those elements is not re-use. It's clarity. The re-use happens in the Sass (or other preprecessor) code. Somewhere in your Sass, you define "basket" as a "pull-left; row; col-xs-4" or even higher level constructs which you plan to re-use... that's up to you. The point is they are orthogonal issues. Creating re-usable chunks of CSS does not suddenly absolve you of the responsibility to make your HTML readable. You can do either one without the other, but you should be doing both.