The horror of Bootstrap classes

A practical guide to sophisticated use of the Bootstrap grid system, how layout and markup can be differentiated using Sass, and why code like the following is horrifying:
<div class="container bg-white text-uppercase pb-2">
<div class="row visible font-weight-bold">
<div class="col-12 col-sm-6 pb-lg-6 rounded">What the f*** ?!</div>
</div>
</div>
“More is more” often seems to be the motto when it comes to CSS classes, which can be used to really over-inflate a web template. Bootstrap documentation inspires people to immortalise the positioning of elements, colours, borders, spacing, text formatting, typography and anything else the heart desires in the markup. But we should take a critical look at whether this solution – which seems to work well – also meets modern frontend programming quality standards.
In addition to extending websites’ load times because, unlike markups, CSS is usually cached by the browser, rigid and inflexible web templates and the bothersome consequences of uncontrolled CSS class management are the result. And this doesn’t just apply to subsequent adjustments and changes; even implementing a template often becomes much more time-intensive.
The regression of frontend programming
If we ignore the ‘responsive’ factor for a moment, many front end developers fall back into old habits as if they are addicted.
In the beginning, programming Internet pages was often done using tables, which were built using all sorts of <table>, <tr> and <td> tags. Then the hype was all about layout and content being separated from one another, and the new age of frontend development was born. Arrangement and design were now forced to take place in CSS, which outlined an immaculate markup based on IDs and classes.
Today we are back at the same point we were ten years ago, except that, instead of table tags, classes like ‘container’, ‘row’ and ‘col-x’ are now being used anywhere possible. If typography, colour and spacing are defined by using CSS classes, the old table style almost seem hip again.
The death of modular templates
Of course to be fair, we should differentiate between the hobby programmers of the upper Bavarian rabbit breeding association (you can find an example here) and professional programmers. Especially when it comes to the latter, templates in CMS systems and online shops are controlled using different modules, plugins, templates and partials.
When implementing a pumped-up version of a Bootstrap class markup, this means planting classes in all HTML files or even at the control levels in the MVC model, which often leads to a great deal of work.
Later adjustments, for example, globally increasing the spacing between modules, result in the need to edit all module templates individually, changing them from an ‘mt-5’ to an ‘mt-6’, for example.
Consistently naming classes
When implementing a web template, the art of programming lies in recognising commonalities and creating global parameters, Sass mixins and classes. A template should be given descriptive classes that can be controlled by CSS:
<section class="content-module"> […] </section>
The ‘content-module’ class defines (as expected) how a content module is displayed. No more, no less. Instead of additionally violating the content module more in the markup with ‘container’ and ‘rounded’, ‘border’, ‘mt-2’, ‘mt-4-md’ and ‘mt-5-lg’, these layout-specific display settings should be globally and generally defined in CSS.
Now, for example, adjusting one individual value in CSS equally increases the spacing of all modules to each other. At the same time, HTML output is reduced and remains transparent and clear.
Sass: man’s best friend
This may be the heart of the whole story. Pure CSS offers virtually no opportunity to replicate even just the four breakpoints of a simple container class. And that’s why Sass is used here. In the above example of a content module class, the characteristics of the container class can be easily applied as demonstrated in the following example. Regardless of which of the three variants are used, the end result is 100% Bootstrap without losing any of the clean structure of the web template.
/* Variante a */ .content-module { @extent .container } /* Varinte b */ .content-module { @include make-container; @include make-container-max-widths; } /* Varinte c */ %wrapper { @include make-container; @include make-container-max-widths; } .content-module { @extend %wrapper; }
Why do all this?
As previous mentioned, you can save a lot of time when modules, plugins and themes don’t require as much rewriting and, at the same time, the readability of the code is significantly improved. Although multi-domain pages or landing pages share the same core files and functions, they need to be given a different look, and flooding the Bootstrap classes with HTML places several obstacles in the way.
If an existing website needs to be given a sidebar that also contains content module classes, instead of using alternative HTML templates, individual characteristics of the container class can simply be disabled to provide the desired results.
.sidebar { .content-module { max-width: none; padding-right: 0; padding-left: 0; } }
Think instead of counting columns!
Just as emergency service personnel react automatically to a medical emergency by taking blood pressure or looking for a pulse, front end programmers usually jump the gun and create a container and a row class. After taking care of the most important points, the remaining course of action can then be planned in the next step.
Using Sass, in particular, presents “new” options here. The following examples thus result in identical outcomes. The first example initially requires 3 wrappers, whereas the second example only needs one sleek h1-tag for the heading. The mixins and variables used are all already available in Bootstrap.
<div class="container"> <div class="row"> <div class="col-12 col-sm-8 offset-sm-2"> <h1>Title</h1> </div> </div> </div>Beispiel 2 - Alternativer Weg mit Sass:
<h1 class="title">Title</h1>
.title { @include make-container; @each $breakpoint, $container-max-width in $container-max-widths { @include media-breakpoint-up($breakpoint) { max-width: $container-max-width / $grid-columns * 8; } } }
Conclusion
Bootstrap is an exquisite tool for creating responsive websites and provides a good deal of support. Of course, in individual cases it definitely makes sense to use classes from this framework, especially if grids can be defined using CMS at the back end, for example. But please, my dear front end programmers:
Before you completely stuff all things large and small with a hopeless mess of Bootstrap classes, start thinking about creating readable templates with tidy semantics again!
Thank you!