7

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

  • 5
    I agree that bootstrap violates SoC, especially with classes like btn-link or mt-n. But what goal does separation of concern help to reach for you? If it is maintainability then, well: bootstrap achieves much better maintainability by other means. Thats totally fine for me. After all, a logically clean codebase that is a nightmare to maintain doesn't help anyone. A codebase that can be quickly adapted to customer needs, many times, without going to shit, helps quite a lot. – marstato Nov 5 '19 at 11:11
  • I understand that bootstrap can add to maintainability in some ways, but it seems to throw so much of the baby out with the bathwater. For instance, say I have an app with 20 screens each containing several tables with lists of items on, and I want all those tables formatted the same. With CSS I can just apply a class to those 20 pages and have all that done for me; with bootstrap, if I don't want the defaults, I have to copy-paste the formatting onto every cell in every row of every table on every page. – Andy Nov 6 '19 at 13:44
  • 2
    not really. First, you can still add a class to the 20 <table> tags and apply custom styling to the cells and rows as you like. Secondly, bootstrap 3 and 4 are written in CSS preprocessor languages (LESS/SASS). If you buy into that you can define a CSS-class to be applied to your <table> tags that applies bootstrap-builtins to rows, cells and other things as necessary without any repetition. – marstato Nov 6 '19 at 15:08
  • Thanks I'll investigate the SASS thing. I knew bootstrap used it but didn't look into it properly yet – Andy Nov 7 '19 at 16:27
  • @marstato Don't forget about javascript interactions. HTML defines the structure, and a highly functional page might depend on that structure. You may want to duplicate or to change the styles of the page, and continue to use the same javascript to provide behavior. In these scenarios, it is much easier to simply swap out the CSS. Regarding maintenance, I agree with others' assertions that SASS/SCSS is the best tool for the job. – Lopsided May 22 '20 at 22:13
6

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.

  • That sounds like a very sensible idea, but it doesn't seem to me that that's the way it's normally used. It also seems a shame that you should have to reverse-engineer the styles they've used so you can apply them yourself in a more CSS-y way. I can't get away from the nagging doubt that there should be some way of getting the benefits of bootstrap without having to throw away so many of the benefits of CSS – Andy Nov 6 '19 at 14:01
  • It's really not that you are throwing away the benefits of CSS, it's just that much of it is hidden and abstracted away so you don't have to drown in the CSS. It's even better if you use Bootstrap Studio to select the components and properties you need. Then you can quickly sketch your page layout, focus on content and JavaScript for awhile, then return to putting the finishing touches on the layout. It's much more productive than most other approaches I can imagine to creating a website or app. – David Spector Sep 14 '20 at 15:10
  • @DavidSpector Bootstrap components are fine, it's bootstrap utility classes that are not. If I have to choose between drowning in CSS and drowning in Bootstrap utility classes, I'd rather drown in CSS. CSS is standardized, have cascading powers, and everyone understands them and what they're supposed to do. Those utility classes are non-standard and you need to understand both CSS and Bootstrap anyway to understand them anyway. Utility classes does nothing to help reduce any practical problems, and is basically just a worst version of inline styles and they make your mark-up hard to maintain. – Lie Ryan Sep 14 '20 at 15:59
  • @DavidSpector Most of the benefits of using bootstrap is from their pre-built grid and components system. Take those, because they're actually where you save a lot of your time when creating your apps. Bootstrap utility classes aren't good abstractions, they're just distractions that takes away most of that savings, and it's a poor excuse for not learning CSS. CSS allows you to do much better abstractions than the utility classes. – Lie Ryan Sep 14 '20 at 16:07
  • @Lie Ryan I have learned CSS, although not all of CSS3. But the Bootstrap utilities are indeed helpful. For example, if you specify a right margin of 16px, how do you know how that will look in your design at various viewport widths, or if you change your typeface or font size? Bootstrap lets you add the class "mr-2", which specifies two units of right margin. This actually means .5rem, but you don't have to remember that, because you develop an intuition for these class sizes, which are simpler than CSS. The main point is that classes are specified in HTML, where most of your layout is. Easy! – David Spector Sep 15 '20 at 16:27
4

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.

  • 1
    Although I'm new to bootstrap, it looks to me that in the real world, the semantic classes are the exception rather than the rule. Specifically, I'd guess that the main reason many people pick bootstrap is because it's an easy way to get a responsive design, and a big part of that is facilitated by the grid model which requires me to specify the relative width of each component in the HTML markup – Andy Nov 6 '19 at 13:50
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.

  • 2
    Not all images are content. AFAICS, all the images added by Zen Garden CSS are presentational. My rule of thumb whether an image is or isn't content is whether the image needs an alt text for screenreaders. If an image is important to understanding the content and you can write an alt text for it, then it's likely content. If an image can be removed from the page without sacrificing information, then it's just presentational. – Lie Ryan Nov 6 '19 at 3:37
  • im talking about images with text in – Ewan Nov 6 '19 at 7:24
  • not all texts are content either, nor are images that contains texts are necessarily content. Texts can be presentational too. – Lie Ryan Nov 6 '19 at 9:16
  • for instance : csszengarden.com/220 the text "Select a Design:" is hidden and replaced by an image which says "Washes and Styles" – Ewan Nov 6 '19 at 9:58
  • that text/image is evidently presentational text. That the text can be replaced without reducing understandability of the content is evidence that the text isn't really part of the content. – Lie Ryan Nov 6 '19 at 10:28
1

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.

0

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.

  • Interesting thoughts. But I'm not understanding "A button or a text field is not a 'concern' ". It seems to be an important concern to me as a designer, so do I specify it in HTML using HTML data attributes, or in a combination of HTML, CSS, and JavaScript, as is frequently done? My claim would be that NOT separating the concerns into different files and languages is simpler and more productive. – David Spector Sep 15 '20 at 16:33
  • Buttons and other input fields are elements that make up a concern, just like in an object oriented program setters and getters are elements that make up an object. The concern is encapsulated in a class. As a designer, yes, you are are 'concerned' about the placement of elements but this is not a 'concern' in the Software Engineering / OO phrase 'Separation of concerns' – verisimilidude Sep 17 '20 at 16:59
  • Don't really understand your point, sorry. – David Spector Sep 18 '20 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.