Things to rethink with Tailwind CSS — Part 1: Breakpoints

After more than a decade of web development, I can say with a clear conscience that I have experienced and learned quite a bit. Much has changed over the years, technologically but also in terms of requirements. If I look at HTML and CSS in particular, there is a world of difference between the time when people tried to implement simple web page layouts for the much hated Internet Explorer and today, when people create complex interaction designs for e-commerce projects and other web applications.

No wonder that it is constantly necessary to throw overboard what has been learned and make room for something new. New ways of thinking, new approaches, new tools.

So a few months ago, I embarked on an experiment and implemented the layout of an extensive web portal using Tailwind CSS. Simply to see if I make and of course how fast I progress, what pitfalls arise and what conclusion I will draw for the use of Tailwind CSS in such an extensive context.

And what can I say, the longer I deal with it, the more I observe how thinking processes and approaches change, how one is almost invited to rethink old traditions and which enormous advantages develop from it for me, my work and the final result.

Of course, I don’t want to keep all this from you and would like to write a small series of information and tips in dealing with Tailwind CSS in the future. So… Welcome to part 1 of “Things to rethink with Tailwind CSS”.

Photo by Matt Seymour on Unsplash

Introduction

First of all, a short introduction to what Tailwind CSS actually is — in case you haven’t heard of it or had anything to do with it.

Tailwind CSS - Rapidly build modern websites without ever leaving your HTML.

In a nutshell, Tailwind CSS is a kind of CSS framework, which provides CSS classes by the utility-first approach to build the desired layout/design by composing these classes directly in the HTML markup.

In addition to this ease of use, low barrier to entry, and truly outstanding documentation, Tailwind CSS has another advantage — with Tailwind CSS, CSS builds include only the CSS code that will actually be used. Thus there is no unused CSS, the file size is much smaller than with conventional CSS and the compile time during development is blazing fast.

Part 1: Breakpoints

If you look at the official documentation, you will find detailed information about breakpoints and how to target them under the “Response Design” section.

The “convection size” breakpoints shipped with Tailwind CSS by default

As you know it from other frameworks like Bootstrap and possibly even are used to, the breakpoints in Tailwind CSS are also named in terms of convection sizes by default. Wonderful, I thought, then it’s even easier to get started with Tailwind CSS since I don’t have to rethink or relearn much about viewports or breakpoints in particular.

Finally, after some time, I was overcome by a feeling, or rather a fundamental question that had been on my mind subliminally for several years, even though it had never really been clear to me.

Are convection sizes really the right way to designate breakpoints?

Somehow this has always felt a little weird. It’s just that it never really stood out when writing CSS or SCSS in media queries like it’s done in Bootstrap for example. Or rather, I just accepted it as it was.

@include media-breakpoint-up(sm) {
  .custom-class {
    display: block;
  }
}

But now that Tailwind CSS gives me the ability to compose utility classes directly in HTML markup using breakpoint modifiers, the scales fell from my eyes.

<div class="text-center sm:text-left md:text-justify"></div>

It’s not really that self-explanatory, is it? Sure, you can see for example “from breakpoint sm the text should be left-aligned”. But what was “sm” again? From where does “sm” begin? And even if you possibly know by heart how the values behind the convection sizes are defined, this is still not very legible.

My recommendation: Rethink breakpoint names

Let’s say you are building a simple website, which should of course be responsive according to modern requirements and you choose the mobile-first approach.

What would you think about giving your breakpoints their own, speaking names. Names, that have a clear reference to the real use case, that immediately inform the developer’s brain about which breakpoint is meant and that also work easily for new developers without any familiarization time?

Let’s break it all down to the real use case! After all, four basic device types (or viewports) will typically access your website — smartphones, tablets, laptops, and desktops.

We take a mobile-first approach, which means that specifying a utility class without a preceding breakpoint modifier automatically applies to every device, starting from the smallest smartphone to large monitor of a desktop computer. So that means we don’t need an extra breakpoint for this case. However, for all larger devices/viewports we need some!

And because the devices are the breakpoints for our brain, we name these breakpoints after the devices. Sounds logical, doesn’t it?

As described in the official documentation Tailwind CSS allows you to customize your theme’s breakpoints as you want or need. And funnily enough, this nomenclature is even pointed out by Tailwind CSS as an example:

// tailwind.config.js

module.exports = {
  theme: {
    screens: {
      'tablet': '640px',
      // => @media (min-width: 640px) { ... }

      'laptop': '1024px',
      // => @media (min-width: 1024px) { ... }

      'desktop': '1280px',
      // => @media (min-width: 1280px) { ... }
    },
  }
}

The adjustments made in tailwind.config.js thus override the default breakpoints of Tailwind CSS (sm, md, lg, xl, 2xl) and instead provide our talking, intuitively usable breakpoints (tablet, laptop and desktop).

In use, this then looks as follows:

<div class="text-center tablet:text-left laptop:text-justify"></div>

Conclusion

Cross your heart! It could hardly be more speaking, more intuitive and thus much easier to use, could it?

In addition: Please read the official documentation on viewport orientation to also shed light on the topic of device orientation (portrait/landscape).

Of course, this recommendation may not work for you, your project, or your team. However, I hope that my article at least inspired you to think about it and possibly implement more meaningful breakpoint names in the future.

Have fun and thanks for reading!