Please stop embedding Bootstrap classes in your HTML | Hacker News Reader

Please stop embedding Bootstrap classes in your HTML

ruby.bvision.com

23 pointscompay10 comments

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.

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.

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.

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

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.

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.

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

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.

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.

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.

Reply on news.ycombinator.com