As a visual designer who has learned to code, I feel that this is not a good idea for the simple fact that it outputs non-semantic HTML (divs are not semantic HTML) and CSS "class soup".
I am all for getting more designers to output code (thus saving a lot of developer time), but these sorts of things not only reinforce non-semantic (& unmanageable) coding practices, but also handicaps those who use them by not teaching them how the web works.
How on earth are div's non-semantic? Most things on a page are just "boxes" -- not lists or links or images or paragraphs, just boxes. And div's are the correct thing to use in this case.
Also, "class soup" is a proper CSS programming practice in many people's opinion -- many CSS style guides explicitly state that it's preferable to use descriptive class names in CSS rules, rathen than element names.
Mainly because, as a site evolves, changing a single element name might break your entire CSS rule structure, while basing your CSS on class names makes everything much more robust and maintainable.
> How on earth are div's non-semantic? Most things on a page are just "boxes" -- not lists or links or images or paragraphs, just boxes. And div's are the correct thing to use in this case.
Because most things on a page are not "just boxes". <header>, <article>, and <footer> are not "boxes" -- they have semantic meaning.
> Also, "class soup" is a proper CSS programming practice in many people's opinion -- many CSS style guides explicitly state that it's preferable to use descriptive class names in CSS rules, rathen than element names.
Everyone is welcome to their own opinion, but I'm of the persuasion that the fewer CSS rules the better. Not only does fewer CSS rules mean that there are fewer things to remember when styling a page, it also means a smaller file is requested.
It's better to use HTML like this...
<article>
<hgroup>
<h1>Page title</h1>
<h4>Written by so-and-so in such-and-such categories.</h4>
</hgroup>
<p>This is a paragraph.</p>
</article>
... than like this ...
<div class="content">
<h1 class="page-title">Page title</h1>
<div class="meta-data">Written by so-and-so in such-and-such categories.</div>
<p>This is a paragraph.</p>
</div>
There is so much more semantic meaning in the former bit, than the latter.
Too, semantic HTML can help with SEO.
> Mainly because, as a site evolves, changing a single element name might break your entire CSS rule structure, while basing your CSS on class names makes everything much more robust and maintainable.
No need to argue with that. Building web apps is a whole other animal, and (having used Bootstrap) I can see why using lots of classes could be beneficial in certain situations.
However, I am still of the opinion that semantic HTML > "class soup".
Semantic html is overrated in my opinion. As if every web page or application could semantically fit the header, article, footer, summary, section, nav, menu paradigm. I'm not against it, but probably, we will have another set of semantic tags in 5 years, and 10 years later yet another set of semantic tags.
> As if every web page or application could semantically fit the header, article, footer, summary, section, nav, menu paradigm
I know, that's the whole thing I'm talking about. A page is full of the div inside the header that centers the header. Then the header has three horizontal bars, two of which are split into right and left side, each of these are full of multiple kinds of items...
These are all <div>'s, and are supposed to be, and they usually make up the majority of elements on any reasonably complex page.
Not every, but 95% do. For the rest, there are other pssibilities and tools to make sense of it (microdata, ARIA attributes, etc). Just ignoring semantics altogether won't do any better.
You're right that a bunch of divs like this is non-semantic. Anyone who thinks otherwise is crazy.
As far as the classes goes though, I would recommend that you check out a style like OOCSS or SMACSS (which I prefer) and give it a shot on a project. I style almost everything with classes currently, and I've found it much easier to maintain and extend than the style that you're describing.
It's a personal choice obviously, but I think you should definitely give it a shot and see what you think.
I've been wanting to try out a number of pre-processors, but I haven't figured out a way to be able to edit it live (which REALLY speeds up development).
However, I'll definitely give SMACSS another (more thorough) look.
This is very wrong, divs are as semantic as you want them to be. If you have an element that looks like this:
<div>
<div>
<div><p>Hello World<p></div>
</div>
</div>
Then yeah sure it's not semantic because you have two unnecessary divs holding a paragraph, but if it was just the one div holding a paragraph tag it would be perfectly acceptable in HTML 4.x onwards. The only cases I can see a div being non semantic are the silly example I gave above, self closing divs in HTML (not extensible) and empty divs.
<div class="content">, <div class="post-title">, <div class="meta-data"> all have semantic CSS class names. But they are not semantic HTML names. Remove the CSS, and all you have is <div>, <div>, and <div>. This makes it difficult for screen readers (and web surfers who don't use CSS (are these people even real?)) to understand what the page is saying.
However <article>, <header>, and <aside> all have semantic meaning that can be discerned whether or not CSS is used.
Also: Whether or not something validates is not a good indicator of it being "semantic".
You cannot use ONLY these "meant to be" semantic tags (<article>, <header>, ...) to describe semantically all the content you have.
Divs is then the only way to go I know.
"Not every, but 95% do. For the rest, there are other pssibilities and tools to make sense of it (microdata, ARIA attributes, etc). Just ignoring semantics altogether won't do any better."
Your understanding of semantics is a bit hazy. Conversely to the pull quote you grabbed from me any semantic element can be used in a non-semantic way.
I am all for getting more designers to output code (thus saving a lot of developer time), but these sorts of things not only reinforce non-semantic (& unmanageable) coding practices, but also handicaps those who use them by not teaching them how the web works.