
Using Bootstrap the Semantic Way - harishchouhan
http://www.ostraining.com/blog/coding/bootstrap-right-way/
======
ZeroGravitas
Still the most comprehensive rebuttal to this common (and I feel, badly
mistaken) complaint:

 _" About HTML semantics and front-end architecture"_ (from March 2012):

[http://nicolasgallagher.com/about-html-semantics-front-
end-a...](http://nicolasgallagher.com/about-html-semantics-front-end-
architecture/)

It's all well worth reading, but the conclusion is particularly to the point:

 _" The experience of many skilled developers, over many years, has led to a
shift in how large-scale website and applications are developed. Despite this,
for individuals weaned on an ideology where “semantic HTML” means using
content-derived class names (and even then, only as a last resort), it usually
requires you to work on a large application before you can become acutely
aware of the impractical nature of that approach. You have to be prepared to
disgard old ideas, look at alternatives, and even revisit ways that you may
have previously dismissed.

...

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."_

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

~~~
ZeroGravitas
I'm not convinced you read the link, rather than just the bits I quoted.

Also, laziness is one of the three great virtues of a programmer according to
Larry Wall. People are getting things done with Bootstrap every day.

~~~
vinceguidry
> People are getting things done with Bootstrap every day.

That is not an argument for correctness of approach. If there arose a cult of
builders who decided to pour foundations with wheelbarrows and bags of
concrete rather than a mixer, I'd tell them they're doing it wrong no matter
how many houses they built this way.

~~~
ryanbrunner
The problem is that you can demonstrably point out objective flaws with using
wheelbarrows and bags of concrete (or I assume you can - I know nothing about
pouring foundations).

With the cult of semantic HTML, the flaws in using class names to describe
presentation are almost always not explained beyond some vague notion of
"correctness", and possibly an example that bears to relation to reality when
you take into account that almost all HTML is being generated by some sort of
templating engine anyway.

~~~
woah
The problem with using wheelbarrows is that it will take a really really long
time to get anything done.

"Semantic" css is like a cult of builders who sort the stones in their
concrete by hand, and will only use the bluish stones for the foundation and
the reddish stones for stairs. You point out to them that it simply doesn't
matter, and they are shocked that you're not doing things the "right" way.

------
droob
We need a better word for this than "semantic". We're just passing the
complexity back and forth between the HTML and the CSS, and the only
"semantics" or meaning that arise are to the author/editor. Users don't care,
machines don't care, and I've never, ever seen a large-scale site design that
doesn't involve some reworking of both the HTML and the CSS.

~~~
rubiquity
That's because you aren't blind.

~~~
droob
In this case we're not talking about ARIA or native elements vs. styled ones,
though, we're talking about CSS classes.

------
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.

------
awhitty
I appreciate the comparison to the ancient Web, but this article doesn't say
much more that I can't find in Bootstrap's documentation.

Anyone who has used Bootstrap's mixins with semantics in mind knows there are
some bigger issues to address than the layout. Some questions off the top of
my head:

* How do you build semantic forms with Bootstrap without going to markup fluff hell?

* How can you avoid the unsemantic class names for components that are tied too closely with child components (I'm looking at you, .panel)?

* What is the semantic purpose of a row element? It seems purely presentational to me.

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

* How should I organize/maintain all of my LESS files as my stylesheets scale? I'm not looking for any one "right" way, but suggestions are always nice.

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

* How can I extend Bootstrap's mixins for my own needs?

~~~
totallymike
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/](http://getbootstrap.com/customize/)

^ Do that :)

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

------
bliker
I think this would be more semantic (with or without the classes)

    
    
         <section>
              <main> </main>
              <aside> </aside>
         <section>

~~~
alxprc
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

~~~
mradmin
You'll also get major specificity issues when using element selectors with
other class/id type selectors. My rule of thumb is classes _and only classes_
for styling, it really makes life a lot easier. (Even if you have a unique
element on the page, don't use the ID in your selector to style it.)

    
    
        <section class="body">
            <main class="content"></main>
            <aside class="sidebar"></aside>
        </section>

~~~
marcosdumay
I have as a rule that if you are in a situation where there can only be 1
element with those properties (it would make no sense at all to have more), I
should use the id.

The top elements are one example. It makes no sense to include them inside any
other element, and if that ever changes, all the styling will need to change
anyway.

~~~
mradmin
What if you had a requirement to create variation styles of those elements?
How would you do that? Would you add you base style in your id selector, and
then variations with classes? Again, you'll face specificity issues with that
approach. Keeping things simple is the best approach here IMO. I've done a
heck-load of CSS and have seen how hacky a stylesheet can become because of
specificity issues. Sticking with classes and keeping selectors short will
make your stylesheet easier to follow and more maintainable, but this is just
my approach!

------
Touche
We do div soup because CSS is still not good enough to do all of your styling
there. When you can trivially make an element 6 columns in CSS we'll all stop
treating Bootstrap like this. Maybe Flexbox version 6 (or whatever we are on
now) finally fixes this but who can keep up and find out.

~~~
spellboots
> 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)

~~~
Touche
Nicer looking div soup is still div soup. <div class="container"> != semantic.

~~~
spellboots
no, but <section> or <div class="products"> are semantic, and there's no
reason you couldn't use those instead of <div class="container"> by using the
features of LESS or SASS.

~~~
ryanbrunner
In my experience, really trying to be semantic ends up requiring gargantuan
leaps of creativity trying to come up with semantic meaning for elements that
are there purely for presentational reasons (wrapper classes, clearfixes,
etc.)

~~~
spellboots
It is certainly hard, and impossible in some cases. But not as many as you
would think. Wrappers can be a problem (although not as much as they used to
be). Clearfix is not a problem at all, as it does not require an element only
a css mixin[1]

Still, it's very possible to be almost entirely semantic with a few minor
exceptions using a css preprocessor.

[1] [http://compass-
style.org/reference/compass/utilities/general...](http://compass-
style.org/reference/compass/utilities/general/clearfix/)

------
kh_hk
Be very wary, though, if you are using mixins to define these columns in a
case-by-case basis, as this could lead to huge generated CSS (the properties
of the column will be defined in each class the mixin has been used).

~~~
spellboots
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](https://github.com/twbs/bootstrap-sass)

~~~
moretti
Less has the same feature: [http://lesscss.org/features/#extend-
feature](http://lesscss.org/features/#extend-feature)

~~~
bluetidepro
Thank you so much for pointing this out, Moretti! It drives me crazy when
people talk about the _extend_ feature like only SASS has it. People are
always underestimating how similar Less and SASS are.

~~~
mikewhy
To be fair, Sass did have it about 3 years before LESS

------
daigoba66
I build web "apps". I don't treat HTML and CSS like a semantic document; it's
just a declarative layout engine. Yes, I often use HTML elements and structure
to define layout instead of CSS classes. My CSS class names often have little
"semantic" meaning outside their single purpose, that is to define layout and
style. Am I doing something wrong? We don't have these discussions when
building native GUIs.

Perhaps if I were building a CMS or some other document-oriented site I would
approach things differently.

------
iambateman
Here is a LESS mixin that will go a long way in making semantic Bootstrap easy
to actually do:

.make-column(@large, @medium, @small, @tiny: 12) { .make-xs-column(@tiny);
.make-sm-column(@small); .make-md-column(@medium); .make-lg-column(@large); }

Then use it with: section#main-content { .make-column(8,8,9,12); }

------
rubiquity
I've used Bootstrap and been forced to use it on existing projects already
engulfed in it. It isn't pretty on a large project. I've sworn off using
Bootstrap in any new project that isn't a prototype for a hack day. The only
things I borrow from Boostrap these days are some of the JavaScript niceties
like modal, tooltip, and scrollspy. And when I do that I'm very explicit in
what code I pull in to use those.

Build the CSS for your next project using mixin libraries like Bourbon/Neat or
Compass/Susy. You'll be glad you did.

~~~
goblin89
> 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.

------
hugofirth
This is one of the main reasons I like AngularJS directives. If used properly
(huge caveat) they allow your template markup to take on far more semantic
meaning.

I also agree with the idea that we should use Mixins to allow for more
semantic meaning in our plain HTML. As an added bonus, this can make things a
lot more maintainable down the road.

------
ZeroGravitas
I just noticed that this article is laid out with a table, with a single td.
Glasshouses, stones etc.

------
jbraithwaite
One of the strengths of BS is mobile-first responsive design. You can chain
classes like this: class-name="col-xs-6 col-md-3"

If you try this with the method outlined by the OP, you'll end up with a giant
css file.

------
grakic
What are current options to optimize LESS files and remove unused mixins? And
for the generated CSS, what are current options to merge shared rules and
remove unused classes reported against a sample HTML?

~~~
shadeless
>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](http://lesscss.org/features/#mixins-parametric-feature)

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

------
hiphopyo
Related:
[https://news.ycombinator.com/item?id=7247054](https://news.ycombinator.com/item?id=7247054)

------
cheriot
This increases the number of css styles dramatically, which affects page speed
on large sites.

~~~
ssorallen
Nicolas Gallagher addresses and deflects this point specifically with real
numbers: [http://nicolasgallagher.com/about-html-semantics-front-
end-a...](http://nicolasgallagher.com/about-html-semantics-front-end-
architecture/#a-note-on-raw-file-size-and-http-compression) 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.

