Using Bootstrap the Semantic Way (opens in new tab)

That's no rebuttal, just an opinion. Oh we got this huge app and are to lazy to do everything properly.

Exactly. I think web devs want to believe that their HTML is purely content and CSS should fully drive appearance but that's never the case. It makes sense to create classes when you can come up with patterns and want to make sure that you aren't repeating yourself everywhere but simply moving the grid system into CSS just adds an extra layer of abstraction that makes it more difficult to read. Also, CSS doesn't support mixins (yet) so you end up with a lot more generated CSS than if you just use the classes.

Fair point. "Abstract" might be better. It embodies the information-/implementation-hiding goal of this technique.

Abstractions still require names, and the names should be meaningful (not easy: "naming things is one of the hardest things to do in software development"), at least to the development team (hate to keep rattling off platitudes, but "you should write code for humans first, computers second"). Rather than "semantic", "descriptive" seems to fit the bill.

"Abstract and descriptive". Doesn't quite roll off the tongue, but I tried :)

I was at Balisage this summer, a markup conference (XML). The opening talk was on semantics. The summary basically read, what the hell does this word even mean anyway.

(paper - http://www.balisage.net/Proceedings/vol10/html/Usdin01/Balis...)

That's because you aren't blind.

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?

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.

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

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

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.

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.

I'm hardly a pro at using bootstrap, but we have been dealing with a few of these things, and I can tell you how we've handled some of these questions:

* How do I add icons without peppering span.glyphicon.glyphicon-X's all over my markup?

This one's fairly simple--you still need to add a class to the span, but you can extend the glyphicon.glyphicon-X bit into a particular icon and call it a day:

    .foo-icon {
      &:extend(.glyphicon);
      &:extend(.glyphicon-foo);
    }

* How should I organize/maintain all of my LESS files as my stylesheets scale?

I'm not sure there is a "right" way, but I'd suggest keeping like things together. You're going to end up with a number of rules that are either dependent upon each other, or at least similar in goal, and they can live near each other. In theory, future refactorings will be easier that way.

* Are there any optimizations I can consider when I'm only using a bit of Bootstrap's functionality?

http://getbootstrap.com/customize/

^ Do that :)

Good luck. If you find answers to the rest of those questions, pass them to me!!

questions 1-4: "Semantic" css is a waste of time. Either you're putting information into the html or you're putting it in the css. Use what works well.

question 5: I'll usually put bootstrap into its own folder, have a style.less outside of the folder that imports bootstrap.less, import stylesheets with custom mixins after bootstrap.less, and import straight up custom styles after that.

question 6: go into bootstrap.less and comment out the stuff you're not using. For the js, use something like gulp-include to concatenate.'

question 7: Load my-mixins.less after bootstrap.less, copy and paste mixins from bootstrap into there, and modify them.

This deeply nested descendent selector stuff is a terrible idea. It's the css equivalent of jquery dom traversal spaghetti. Don't overthink things. Css should be good enough, and no better.

Sure, but what if you have more than another section that should be styled differently? Classes can help differentiate same-name elements with different contexts, so you don't need unwieldy structure-specific CSS selectors like

  main > section > main

just

  main.semantic-class

> When you can trivially make an element 6 columns in CSS

As demonstrated in the article you can trivially make an element 6 columns in LESS (or SASS, which has a bootstrap port also)

Alternatively use SASS (and the bootstrap SASS port[1]) which doesn't has this problem, as it instead rewrites selectors.

i.e. if you have:

    .column {
      width: 100px;
      display: inline-block;
    }

And you do:

    .cool-sidebar {
      @extend .column;
    }

Then the generated css will be something like:

    .column, .cool-sidebar {
      width: 100px;
      display: inline-block;
    }

[1] https://github.com/twbs/bootstrap-sass

> I've sworn off using Bootstrap in any new project that isn't a prototype for a hack day.

I believe initially Bootstrap was intended for just this use case—make it easier to do a quick mock-up in markup. Once your design is relatively stable, you would naturally spend some time custom-fitting markup and stylesheets (enhancing source code readability, accounting for those who can't see, basic SEO optimization, etc.). This whole ‘front-end framework’ thing seems to me like a wrong direction to take.

Frontend is my bread and butter, and I used to be such an artiste that I shunned Bootstrap too.

But you know what's worse than Bootstrap? The hand-rolled framework that rises out of the muck on a large project. At least Bootstrap is always the same. It's a lingua franca, and a decent one at that.

>What are current options to optimize LESS files and remove unused mixins?

Kolega, use parametric mixins without parameters: http://lesscss.org/features/#mixins-parametric-feature

For unused css I'd try this: https://github.com/addyosmani/grunt-uncss

I got this recommended for handling shared rules: http://zmoazeni.github.io/csscss/

Nicolas Gallagher addresses and deflects this point specifically with real numbers: http://nicolasgallagher.com/about-html-semantics-front-end-a... The link came from an earlier poster. Once you compress the HTML, the savings are insignificant compared to the likely 10s or 100s of kilobytes of images and JavaScript on a modern web page. Given how tiny the savings are, there are other places more worth your time to save bytes.