[camus2]

The point of using bootstrap is a reusable set of classes. I really dont care wether class names are semantic or not,it doesnt change anything,except for pedantic people looking at your source code.

SEO doesnt care , users dont care, accessibility doesnt care either. Using new HTML5 tags is good enough and was designed for that specific purpose. If i want semantics I use nav,aside,section instead of div,and so on.

Not going to waste my time and wrap bootstrap mixins in more LESS mixins and loose theme portability and modularity,because semantics...

It's like inobstrusive javascript, trends that make little sense today in the webapp era.

[hugofirth]

Couldn't disagree more with your statement. What if you have a sidebar that appears 20+ times throughout your application in different contexts. You might decide it is too wide. Are you going to go through all your templates and change class="col-md-blah" or are you going to change one mixin?

Also, if you are providing a theme, I don't see how you lose portability. Your mixins will be relying on base bootstrap anyway?

[ryanbrunner]

For pretty much anything anyone could describe as a "web application" if you have the HTML for your sidebar copied around 20+ pages instead of stored in a common template somewhere, you have bigger problems than whether your HTML is semantic.

[hugofirth]

The example was contrived to prove the point. I agree that the specifics of the Scenario would be indicative of poor practice in other areas, but that doesn't change the fact that the markup should be semantic.

[Touche]

This is what is great about decorators (the most awesome part of Web Components that probably will never be implemented):

http://www.w3.org/TR/components-intro/#decorator-section

[kh_hk]

You will start caring the day you want to update to Bootstrap 9000 and need to change the class names of all the properties that have changed. A counterargument could be that one could stick with the version already deployed, and that's fine too I guess.

For me it's about being in control of the situation. I will find myself changing things just for them to look as they are supposed to look like, and soon realizing that is not CSS anymore, just another framework being in between and making the work sometimes easier and sometimes harder. Using LESS at least gives you a bit more of control on the hidden spots, and opens room for sane customization.

I do personally prefer to not use a CSS framework at all, but if Bootstrap is a requisite on a project, using LESS is a no brainer.

[dsego]

Bootstrap already depends on the markup structure, which makes your point moot.

[kh_hk]

I do not really get your point, care to elaborate? Unless you mean that 'div' is subject to change over time…

[dsego]

A span2 div needs to reside in a row or row-fluid div for it to make sense. You can create your own classes that inherit from these, but you still need to nest them. Which means you can't change the structure of the markup willy-nilly. Thus, not using boostrap classes won't get you far.

[jey]

This sounds exactly like the complaints lodged against structured programming[1] by traditional GOTO-based programmers.

1. https://en.wikipedia.org/wiki/Structured_programming

[allendoerfer]

Except, that the idea of semantic web is the traditional approach, whereas composable cross-browser classes controlled with LESS variables is the new and more pragmatic approach.

[jey]

Sounds like you're confusing Semantic HTML with Semantic Web. "Semantic" HTML is a style of writing HTML where the document exposes the meaningful structure and data in the document instead of the visual layout. The idea is that HTML is just a structured data representation, a la XML, and CSS is then used to transform it into a particular layout.

https://en.wikipedia.org/wiki/Semantic_HTML

[allendoerfer]

You are right, I meant to write "HTML". Nevertheless I question the usefulness of this approach. Semantic XML vs. pragmatic JSON tells a similar story.

Semantic structures are never perfect, because they are not controlled by the recipient, but by the sender. I love the idea, but I think it will never come true. We will always have to mine the data ourselves.

I can see the value of providing semantic markup for screen readers or for some Google SERP extension, but I do not see how semantic class names provide any value at all.

Separation of concerns is a nice saying, but as other comments already mentioned, is just not possible to the full extend yet as CSS and browsers are to limited.

I think we should acknowledge these shortcomings and real world circumstance, do our best to work around them, but in the end just move on and be productive.

[dimal]

Perhaps the term "semantic" is overloaded, but there are good reasons why presentational classnames are bad, even though users don't care and machines don't care. Your fellow developers should care. When done well, semantic markup is much easier to maintain and reason about. There's far less duplicated template logic and design changes are much easier because it's easier to understand where your changes will have an effect. The generated CSS might be slightly heavier, but possibly not. Poorly architected CSS tends to get very bloated and heavy very quickly. And there are better preprocessors like Sass or Stylus give you more options for keeping you generated CSS to a minimum. Less is really the worst preprocessor out there.

Every non-semantic bootstrap site I've seen has far more templates than would be necessary the templates only spit out minimal markup with classes that say what each element is instead of what it looks like.

But now we have tons of developers whose primary skill is backend development that are able to mash together a reasonable looking site without understanding how to create maintainable front end code. When the design changes, they just keep piling on more markup and more classes. This works for a while, but as designs get iteratively tweaked and changed, and kludges pile on top of kludges, the markup and CSS become a huge tangled mess. Making changes can have unpredictable effects on other parts of the site.

And then the back end developers throw up their hands and say, "CSS is stupid." But users don't care if the code is a mess, right? Machines don't care either. But the front end dev -- the one who's tasked with getting the new design to work without breaking anything else on the site -- he cares. And he's gonna have a bad time.

[rimantas]

Insert an anecdote about the carpenter and the quality of the back of the cabinet there. Except in this case it matters a bit more as others pointed out already.