
Please stop embedding Bootstrap classes in your HTML - compay
http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-classes-in-your-html
======
scopestar
I have to disagree with you here. The 'row' and 'span' pieces are a small part
of the overall bootstrap package. If we leave them aside for a moment (and
come back to them later), I think most of the Bootstrap class names are well
thought out and even "semantically" meaningful. If I'm going to show a button
and its the primary button, I could to much worse then a class named btn-
primary. Same goes for alert-warning, progress-info, page-header, etc.

The purpose of the library is bootstrap. I've seen much worse choices made by
web sites that don't employ consistent approaches towards semantically
meaningful class names then bootstrap is using. If down the road, after my
"bootstrapping" days are done I want to overhaul my css, I can redefine,
extend or whatever I want with a class named 'alert-info'. But chances are
pretty good that whatever I want this alert box to look like, it is still
going to be an info alert box from a semantic standpoint. I'm not really
"hardcoding" anything. I'm using a consistent naming convention for my
semantically described elements/components. Have I really accomplished
anything better by giving my alert-info box a custom name of my-alert-info-
box?. I argue no. If the class name was 'bootstrap-red-square-box' that would
be a different story.

As far as row and span thing goes, you have to pick your poisons. A lot of
people use grid layout systems (blueprint, 960, etc.) and most of these
require some row, span, column, gutter class markup. I think people have
pragmatically learned over the years that while we don't want to force layout
into tables (because they have a different semantic purpose), the holy grail
of 100% layout free css class names my not be worth the cost. Generally a
layout change requires some markup change no matter how pure your naming is.

I wouldn't throw the whole Bootstrap class naming convention overboard just
because of the row and span thing.

~~~
compay
I agree many of the class names are well-chosen. But maybe they're not fine
for every application. And Twitter may change them between versions (as they
already have).

The point is not to completely avoid using their naming scheme - the point is
to avoid unnecessarily depending on it throughout all your HTML files, when
you can easily isolate the dependency to a single Less file.

If you're using something like Less or SCSS, there is almost no need at all to
depend on the class names, you can use them or not use them as you see fit. We
wrote the article because a lot of people are not aware they have a choice.

------
smacktoward
From the article:

 _> This is why table-based layout fell out of favor._

No. No. No. No it is not.

Table-based layout didn't fall out of favor because table cells didn't include
enough semantic layout information. It fell out of favor because _tables are
for tabular data, not layout_ , and layouts that used them therefore created
negative consequences in all kinds of situations where the UA expected a table
to actually _be a table_ , such as when accessed by a vision-impaired person
using a screen reader.

From this perspective a layout using DIVs is _always_ better than a table-
based layout, even if the classes and IDs of the DIVs are named
presentationally rather than semantically, because DIVs at least are neutral
-- they don't carry the weight of a bunch of semantics that are irrelevant or
at cross-purposes to what you're trying to achieve.

You are correct that a DIV that's named "left-column" is _marginally_ better
than a DIV that's named "span4", if only because of the additional semantic
information included in the "left-column" name. But _either_ DIV is far, far
better than any table-based layout.

~~~
compay
Perhaps we were unclear. Coding layouts in tables _is_ coding towards
appearance rather than meaning, hence the problems you described.

~~~
smacktoward
No, you weren't unclear, you just completely missed my point.

Coding layouts in tables is _more_ than just "coding towards appearance." It
is _misusing a non-appearance-related element_ , which is _worse_.

The problems I described don't come from "coding towards appearance," and they
aren't encountered with DIVs named presentationally rather than semantically.
You only get them with tables, because you're _abusing the table element_ by
using it in ways that are completely orthogonal to its purpose.

I'm not disagreeing that semantically-named DIVs are better than
presentationally-named DIVs. What I'm saying is that presentationally-named
DIVs are not equivalent to table-based layouts. Table-based layouts are worse
than ANY DIV-based layout, regardless of how the DIVs are named.

------
danso
Going to throw in the expected rebuttal: When was the last time someone did a
major CSS overhaul without changing HTML?

In any case, for someone developing with a framework, they're already mucking
about with templates, in which editing the classes is trivial to alter.

~~~
compay
> When was the last time someone did a major CSS overhaul without changing
> HTML

True perhaps, but that's because lots of people write poor-quality HTML. By
following best practices like this, it becomes much less necessary to overhaul
your HTML during a design change.

~~~
bronson
If only that were the case. HTML and CSS are super tightly connected. Want to
change a float? You probably need to reorder your HTML Want to change some
margins? Time to re-nest some elements.

Even the finest HTML in the world often needs to be modified when the CSS
changes. It's a shame but them's the tools we have.

~~~
compay
We just completely redid the design of our site and barely touched the HTML
other than the top nav, and that's mostly because the content changed there,
and the changes were mostly deletions.

In my experience a lot of developers solve problems using HTML that could be
better solved with CSS and a sprinkling of Javascript, because they don't know
the DOM or CSS well enough. I think that's what most often leads to the
situation you described.

------
mrxd
I was once on Zeldman's semantic CSS bandwagon - Designing with Web Standards
was the Bible for me. Not anymore. Now I think it is a huge mistake that
creates unmaintainable CSS. Here's why:

Let's say I want to style a box to hold an image and a caption that goes in a
blog post. Semantic CSS would have me do something like this:

    
    
        div.post div.picture {
            border: 1px solid #ccc; background: #eee; padding: 8px; font: 11px/15px georgia, sans-serif;
        }
    

This is OK, except this style is almost the same as a newsletter subscribe box
in the sidebar, and I'm duplicating all those style here. DRY - no problem,
I'll just stack the selectors:

    
    
        div.post div.picture, div.moreinfo div.newsletter-subscribe {
            border: 1px solid #ccc; background: #eee; padding: 8px;
        }
    
        div.post div.picture {
            font: 11px/15px georgia, sans-serif;
        }
    

But wait, that border style is being used in the nav too, so...

    
    
        div.post div.picture, div.moreinfo div.newsletter-subscribe, div.nav {
            border: 1px solid #ccc;
        }
    
        div.post div.picture, div.moreinfo div.newsletter-subscribe {
            background: #eee; padding: 8px;
        }
    
        div.post div.picture {
            font: 11px/15px georgia, sans-serif;
        }
    

We can continue with this, but you see where it is going: a huge stack of
selectors followed by a declaration of one or two properties. This is
obviously bad: the style for any given element is spread out in lots of
different parts of the stylesheet file, or even multiple files. If I want to
add a new element, I have to copy my selector into all those different points,
every single time. Even if my new element has the exact same style and the
only difference is that it has a different semantic meaning. Obviously, this
is too much of a pain, so Semantic CSS encourages defining independent
components with lots of redundancy.

If you're using a CSS preprocessor (which were not around when Designing with
Web Standards was published), mixins partly mitigate this problem. All my
rules can inherit shared styles. But there is still a problem: every time I
want to use a style, I have to edit a CSS file. With Bootstrap, the process
for using a zebra table is copy and paste the boilerplate HTML from the
component library - done. The Semantic CSS way is to come up with a new
semantic class name (".users-table" or whatever), find out where in the CSS
the zebra table is defined, add the selector and now I can start using it. So
now the whole dev team is constantly checking in changes to a shared CSS
library for no purpose other than to register the fact that they are using the
component, and the CSS files get bloated with hundreds of meaningless
selectors.

This blog post cleverly proposes a separate CSS file to map semantic CSS names
to style definitions - ".users-table { .table-zebra }" - adding an extra level
of unnecessary indirection. Or worse, a line of javascript. Why? On the off-
chance that you might want to switch to another CSS framework that just so
happens to use Bootstrap's markup, but not its class names?

The only thing Semantic CSS gets right is that classes shouldn't be
descriptions of the properties. But there is nothing wrong with .span6 instead
of .feature, or .btn-primary instead of .editUserFormSaveBtn.

tl;dr - Semantic CSS is a red herring that creates more problems than it
solves. These problems weren't noticed because it was invented and promoted by
people working on very small marketing websites without much code reuse, and
is totally inappropriate for web applications of any size.

