Years ago, we moved away from layout with tables because <table><tr> is a horrible way to separate presentation from content but <div class="two-thirds columns"> is just as bad.
Classes on elements exist for the purpose of styling via CSS, not for users to see or screen readers to read or googlebots to classify. So if you want your css classes to "mean something" (which is what "being semantic" is), you want them to mean something to the STYLE of your page! Hence, using class="two-thirds columns" is perfectly semantic towards the purpose of visually styling the page.
Did you have some other interpretation of "semantic" that you think should apply instead? Perhaps you mean "the structure of the content"? That's not what classes are for -- that's what the elements themselves are for. Or perhaps you mean for visually-impaired folks to be able to easily navigate the content? That's not what classes are for either -- that's what ARIA roles are for. SEO perhaps? It's possible that google uses class names for this, but that's just black magic voodoo that us mere mortals can have no knowledge about (and even if we did, it could change tomorrow).
Here's the thing about using tables for layout... the table element actually has a defined meaning in HTML... it is for tabular data. The div element however does not imply any meaning (other than "arbitrary division of the page"). So using a div here with the classes that imply meaning to the CSS is quite "semantic" in this case.
To change how wide a column is, you change its class. To change how wide an image is, you go into the CSS. To change how wide a column's border is, you go to the CSS. Doesn't changing the class seem a little out of place?
In theoretical terms, the class is semantically the category to which the component belongs. a <section class="cart"> is perfectly reasonable, whereas <div class="two-thirds columns"> is not. The <div> and it's children are not tied to the notion of how wide the div is. The fact that a section has class "cart" is important in understanding it's children.
I totally understand your point, and I'm kind of being obtuse for the sake of argument... but I do think the term "semantic" is thrown around without people really thinking about "semantic for whom" or "towards what purpose".
Those things aren't supposed to exist. HTML is supposed to look like:
<div class="blogpost><h1> ...
<div id="mainmenu"> ...
If semantic in terms of HTML is ever thrown around meaning anything but description of the content, it is used wrong.
The question about "semantic for what purpose" is moot when talking about HTML. It is semantic towards what information the content conveys.
"Semantic HTML is the use of HTML markup to reinforce the semantics, or meaning, of the information in webpages rather than merely to define its presentation or look."
https://en.wikipedia.org/wiki/Semantic_HTML
The question of whether that is feasible to do with current technology is completely different, but it is too late to try and redefine semantic HTML.
Everything is so loosey-goosey with HTML. HTML5 sectioning elements are a huge clusterfuck, no browsers utilize the document outline and screen readers primarily rely on ARIA roles. Google uses black magic to figure out what documents mean... so the "html can only contain information that defines the content" ship has sailed. You need to have divs in your html to achieve certain layouts. As long as those divs need to be there to serve that purpose, why not use class names that are related to the purpose you're using them for?
This is very different from table-based layouts. The <table> element does have a defined meaning! But div's do not... so using divs and styling them with CSS achieves proper separation of concerns. The label you use to describe them only has meaning to you (the designer/developer).
I'm not saying that semantic HTML is working today. But just because it isn't working doesn't mean we should start calling what is working for semantic HTML.
Markup written this way is, imo, indeed more readable, maintainable, and less likely to change. Whether you agree with that or not, that's the meaning of "semantic" in CSS arguments.
The argument here is similar to the argument for writing declarative code, or, in OO, for ensuring that your objects, and their names, match natural domain concepts. The rates of change of such concepts are generally much slower than the rates of change of their concrete manifestations in views.
The way I see it, that thing is a boundary for the grid. In fact, I bet if you narrow your screen, that "thing" changes the way it looks entirely and is no longer a "column" but rather stacks above or below its counterparts within the same grid "row". If you used the class "left-navigation", to me that's describing how it looks even more than saying it's a "grid column" (because the navigation won't be on the "left" on narrow screens)!
Of course your example of class="category-navigation" does not suffer from this problem, but again my point is that sure it's more "pure" from the perspective of describing the element's place in the overall structure of the page, but this is not the purpose of the 'class' attribute! The HTML5 elements are for structuring the content... but classes are hooks for styling the content. As long as the styles themselves are not intermingled within the HTML, I think it's no more or less "semantic" to use words that imply meaning to the css versus the content itself.
Finally, in my experience building tons and tons of CMS-based sites over the years, the "meaning" of the content that exists in a particular location of the page changes a lot more frequently than the visual layout of the page. So I'd argue that it's more likely (in my experience, for the kinds of sites I tend to build) that using "column" as a class name will keep its intended meaning for much longer than using something like "category-navigation" (because one day someone in marketing is going to want to put a CTA button or more social links in that spot that you originally intended to be for "category navigation").
http://nicolasgallagher.com/about-html-semantics-front-end-a...
Conclusion:
"When you choose to author HTML and CSS in a way that seeks to reduce the amount of time you spend writing and editing CSS, it involves accepting that you must instead spend more time changing HTML classes on elements if you want to change their styles. This turns out to be fairly practical, both for front-end and back-end developers – anyone can rearrange pre-built “lego blocks”; it turns out that no one can perform CSS-alchemy."
Edit: Curious why this is being downvoted. Is humor (intelligent humor in this case IMO) really that frowned upon at HN? Or did someone think I was calling the parent commenter a "Wannabe Web Standards Advocate"? (I certainly wasn't. Quite the opposite.)
For example: http://neat.bourbon.io/
div#alpha {
@include span-columns(1);
}
div#beta {
@include span-columns(11);
}
div#gamma {
@include span-columns(2);
}
...It's a nice idea, but falls over pretty spectacularly in the real world when you have a complicated web application.
But I didn't find any good tutorials on this.
Also, I don't know how this should change the html-elements needed by stuff like the bootstrap components.
1. Create your HTML using only semantics. If you're tempting to create a class called, say, "column" or "left-container", stop yourself. If you have multiple items that will be presented the same way, give them the same class. For a shopping site, for example, a class might be "product".
2. Use a CSS preprocessor to inherit non-semantic classes from your framework of choice into the classes you created in step 1. You might use the framework's classes as they are or modify them a little.
This may work for simple cases. But what about stuff like the Bootstrap components, which consist of many HTML-elements?
This works really well on projects that have a dedicated design team.
A. You can compose components the same way Bootstrap does, but using semantic classes. For example, if Bootstrap is using "thumbnail-container", you could call your class "product-thumb-container". Because of the way HTML works, container classes are often necessary, and they can be semantic. Think about a legal document: at the end of them, you have appendices. An appendix is like a container: it's factored into the overall structure, but it also has a semantic value. You can't move an appendix somewhere else and still call it an appendix.
B. You can use only the parts of Bootstrap that you want, so you could leave components out altogether. As mentioned above, this might be a better option for a larger project with fine-grained, custom designs.
I'd recommend SCSS if you're just getting started.