Does bootstrap break separation of concerns and defeat the purpose of CSS?

Question

Although I have seen a few Bootstrap sites, I have only just started to look into it seriously and I was quite shocked by what I saw in the HTML - loads of nested divs with multiple classes attached to each.

In the old days before CSS, people used to decorate their HTML with fonts, colours, etc., and this was considered a "bad thing". CSS enabled the HTML to be very clean and free of styling information. This is "separation of concerns" which is considered to be a "good thing".

Although the styling in bootstrap has a level of indirection (i.e. it references class names rather than directly specifying colours etc.) it is basically putting the styling information back into the HTML instead of using CSS as it was intended.

Don't get me wrong, I have written enough CSS to know how difficult it is to maintain, so I can understand how bootstrap came about. My question is really whether bootstrap is seen as a hack for people who want to knock up a site quickly and don't care about separation of concerns, or whether it's actually considered a good practice to keep the style information close to the HTML (which you could argue is a kind of encapsulation) rather than lumping it all together into a separate file (i.e. that CSS wasn't really the right solution).

Answer 1

My question is really whether bootstrap is seen as a hack for people who want to knock up a site quickly and don't care about separation of concerns

A lot of Bootstrap utility classes are useful hacks to get a site up and running quickly yes, but if we ignore the utility classes, most of Bootstrap's components are actually well designed reusable components that can mesh well with semantic markups and they're fine semantically speaking (although they do force you to use their naming, and standardization isn't necessarily a bad thing).

My principle when marrying Bootstrap and Semantic markup is that you don't want to drink too much of either side's Kool-Aid. They're both fine techniques to help solve problems and minimise the cost of maintenance, but they both also can create their own set of problems if you inconsiderately apply the good basic principles without fully understanding when or why the techniques are done certain way.

Generally, you should be writing most of your major site components with plain old semantic markups and define useful blocks of functionality in your CSS; use Bootstrap for its reusable, composable components here and there are ok (i.e. don't build the entire house with Bootstrap, but using Bootstrap-branded windows and furnitures are perfectly fine). The Bootstrap components are great because it gives you a common language to talk about the common components of a site in higher level than raw HTML/CSS, and it allows you to prototype really quickly.

It's really great to have decent looking, well tested buttons, forms, and basic grid system without having to write huge amount of code yourself. But you also don't want restrict yourself to Bootstrap, as you may find that forcing Bootstrap beyond the basics often lead to worst maintenance nightmare than straight styling.

However, Bootstrap utility classes should be used sparingly, reserved for minor tweaks where practicality beats purity, rather than building your primary layout definition with it. If your tags have class attributes that are mostly utility classes, you're doing it wrong, IMHO.

Most Bootstrap utility classes are essentially just wrapper classes for one liner CSS. And having to add them everywhere it's used can make your HTML code look very unreadable and bloated, with all the problems of inline style attributes. They certainly don't make the code more maintainable.

Answer 2

Depends. Bootstrap can be used both ways. Many bootstrap classes are semantic, so does not break separation of concerns. E.g.

<div class="alert alert-danger">Beware of the leopard</div>

This is perfectly in line with how CSS is supposed to be used.

But bootstrap also have classes which are more directly coupled to presentation, eg. btn-dark, btn-xl which define presentation properties rather that semantic properties. That is not exactly in the spirit of CSS - but it is still much more maintainable than having e.g. font-size specified directly in the HTML.

Answer 3

I think a de facto truth that complete separation of style from content via HTML and CSS is not possible.

Take a look at http://www.csszengarden.com/

At first glance it looks like the perfect demonstration of separation of content and style. But if you take a close look at some of the more advanced designs they are putting content in the css via background images and the like.

On a modern single page site you bring javascript frameworks into the picture, which will add and remove style and content dynamically.

Rather than achieve the goal of a simple layout language which left the display to the browser, HTML has become a vehicle for displaying pixel perfect designs where sites only function at all on advanced browsers.

Answer 4

This thread has convinced me that current CSS does not have (and probably cannot have) completely separate concerns from HTML.

I have never felt comfortable with the SGML (Standard Generalized Mark-up Language) approach that inspired HTML (see https://www.w3.org/People/Raggett/book4/ch02.html). SGML is a semioticist's metatool for abstracting "meaningful" content from a presentation document, an activity that is mostly only the concern of Web Bots (or pure data processors, such as XML and JSON) and can always be achieved more or less easily through context-free grammar parsing. Few people need or want a browser that only shows the abstract content of a website (a header, an article, and a footer as a pure structure of text). As such, this "separation of concerns" concept is inherently foreign to the modern Web.

Using three or more separate languages never seemed to me the right approach to quickly and concisely describing a Web page, since each file deliberately leaves out so much that makes a Web page useful, attractive, and meaningful. Abstraction is fine, but SGML and HTML do it the wrong way.

I spend a lot of my time thinking about ways to specify Web pages, and I have not found that using multiple files or languages (except for expressing levels of hierarchical abstraction, such as specifying a particular navigation menu as opposed to how to construct a menu in general, or specifying a particular text control as opposed to how to construct any control) is the best approach. The present structure of PHP, HTML, CSS, Aria, and JavaScript supported by all modern browsers and servers is difficult to learn and filled with gotcha's that require frequent Web searching to resolve. And that is ignoring React, Angular, .NET, Ruby on Rails, and dozens of other frameworks and languages that each do things their own way.

I think that Bootstrap (and tools like Bootstrap Studio) represent a good start towards making Web design easier and simpler, but doesn't go nearly far enough in eliminating the need for separately considering words, graphics, pixel-perfect and responsive layout, and event functionality, which are all closely-connected elements of modern website and app design that are currently supported by a variety of languages and frameworks presenting a very high overall learning hurdle.

Answer 5

Separation of Concerns means being able to define the concerns first and HTML + CSS / SASS + Javascript + XML/JSON ... are just too fragmented to allow concerns to be defined in any way other than the way they were defined when the languages were drafted.

A button or a text field is not a "concern", the "user list" is a concern but there is no way in current web standards to separate "user list" out that would bundle up all the aspects covered by the web standards listed above and just drop such a control into a web page even assuming a nice web api to call for the back end functionality.

Long before the web graphic designers used a "Grid" to produce layout, but HTML (and its roots in SGML) specifically divorced the content from the grid, something no graphic designer would do. (e.g. The Logo must be the most obvious thing on the page.) So to the designer the logo is the concern and its visual representation is what is important. You can't specify all aspects of this concern in any one standard web language.

Answer 6

I recommend the blog article CSS Utility Classes and "Separation of Concerns".

It starts with the typical approach, where you define all styles in CSS. The author shows that the CSS structure is still tightly coupled with the HTML, and the separation is an illusion.

The author then gradually works toward re-usability over separation of concerns. And finally, instead of creating your own set of classes, you can start with a library and then add your classes on top of it.

My concern is that in libraries like bootstrap you have to learn and memorize many CSS-classes. For beginners, this means spending time learning a framework instead of learning proper CSS first. Moreover, with bootstrap you create a ton of encapsulated DIVs instead of using semantic HTML tags.