Be the browser’s mentor, not its micromanager

Back in 2022, I presented a talk with the same title as this lesson. You can go ahead and watch it if you like. There’s also a companion website that might be useful as a reference to you, ongoing.

I want to spend a little time covering some important parts of that talk and also a project we at the studio put together last year. It demonstrates you truly don’t know what viewport your users might be using.

A bit of history of responsive designpermalink

In 2010, Ethan Marcotte published Responsive Web Design. At the time, iPhones were sort of capturing the mainstream, but overall, the mobile browsing experience was frankly, awful. When Ethan published his article, leveraging media queries to provide responsive layouts, the industry shifted permanently.

Also, at that time we were supporting some extremely bad browsers in our day-to-day work. We were building responsive websites with this new, not widely supported tooling, while also making our websites work with the infamous Internet Explorer 6 — truly the worst browser.

With this extremely difficult situation, we naturally, but naively aimed for total control. We utilised polyfills and hacks to get things working just so. By just so, we were of course aiming for the unachievable: pixel perfection across all browsers and devices.

As Jeremy Keith covers so well in Resilient Web Design, we were bringing traditional design practices into a very quickly maturing and profitable industry: web design. These traditional design practices were like a comfort blanket.

It was as though the web design community were participating in a shared consensual hallucination. Rather than acknowledge the flexible nature of the browser window, they chose to settle on one set width as the ideal …even if that meant changing the ideal every few years.

Jeremy Keith — Resilient Web Design

We were fighting a losing battle trying to get pixel perfection in browsers. At the same time, job roles were changing. The title of front-end developer really took hold while web designer fell off. We started to see roles like product designer and UX designer come around too. It was truly a changing of the guard, but we picked up some bad habits along the way and lost sight of what was important.

Where this leaves us todaypermalink

We, friend, have not learned our lesson. Even now, in 2024 a lot of companies — I’d argue most — are doing the old design a website in a design tool like Figma or Sketch, then throwing it over the fence to developers, who then throw it back, get a mile-long snag list, and force the browser to achieve so-called pixel perfection.

The problem with this is the ideal viewport doesn’t exist, as we outlined in viewports.fyi.

Out of the 120,000+ viewports we captured in a 48 hour period, overwhelmingly, the most common, were so-called mobile viewports. I prefer to call them small viewports because who’s to say they are actually mobile devices?

This is the thing about browsers: you can do pretty much whatever the hell you want and rightly so. There’s no stopping you from making your browser whatever size you want. There’s also nothing stopping you from installing whatever extensions you want either. Oh, let’s not forget users can literally write custom styles for websites. All in all, we have little to no control over what the user sees.

Some might panic at this realisation, but no, don’t do that. Change your mental model to be the browser’s mentor, not its micromanager instead.

What the heck do you mean by that?permalink

Let’s look at a typical set of breakpoints that you tend to see in a project. You’ll likely get a “mobile” one which is around 350px, a “tablet” one which is about 750px and a desktop one which is around 1020px. You might have a few more to capture much larger or smaller viewports, but that trio is pretty standard now.

We then use these with the CSS @media capability like so:

@media (min-width: 350px) {
  /* Mobile styles */
}

@media (min-width: 750px) {
  /* Tablet styles */
}

@media (min-width: 1020px) {
  /* Desktop styles */
}

What about the sizes in between though? Do we make a huge collection of media queries like this?

@media (min-width: 350px) {
  /* Mobile styles */
}

@media (min-width: 500px) {
  /* Sorta mobile but maybe tablet styles */
}

@media (min-width: 750px) {
  /* Tablet styles */
}

@media (min-width: 820px) {
  /* Bigger tablet styles */
}

@media (min-width: 1020px) {
  /* Desktop styles */
}

@media (min-width: 1200px) {
  /* Larger desktop styles */
}

@media (min-width: 1500px) {
  /* Big desktop styles */
}

Pretty unsustainable, right?

Back in 2019, I co-authored Every Layout with my good friend Heydon Pickering. In that book, we argued that building rigid media query powered layouts was more harmful than helpful. In fact, we argued that building in a rigid, specific fashion was harmful too. We provided some flexible layout systems that gave the browser rules which it could then make its own mind up about.

This is the key: instead of forcing the browser to do what you want, give it a sensible ruleset and let it determine what’s best for the user based on their actual circumstances. We do this with flexible layouts, fluid typography and spacing (we’ll get to that in the next lesson) and semantic, well structured HTML.

The result: by letting the browser do the work for us, users will get a better experience that works for them, and most importantly, that works well. Sure we lose “control”, but we give that actual control to the people that need it most: the fine folks looking at your website.

“Yeh but we have container queries now”permalink

We do indeed have container queries now, but let me try to re-frame how we should use both container queries and media queries.

Instead of using them for everything, I’m going to show you how we can use them as useful tools where more control is required in complex UI patterns, rather than using them for everything. By letting the vast majority of our front-end provide simple rules for the browser, the user is already going to get a solid experience that works for them. Us adding a little bit of control presents a limited risk of damaging that experience.

I’m convinced that at the end of this course, your mindset will be completely transformed by this approach.

We shouldn’t be in the business of building pictures of websitespermalink

Ok, let’s wrap up this lesson with a principle to carry right through the project. As mentioned earlier in the course, we’re working in a traditional design hand-off setup, because I know most of you are working like that in your jobs.

It would be irresponsible of me to not teach you in the environment you’re already working in because I know how it goes in companies from my years of consulting experience. You can’t get huge changes of process through the door easily — sometimes not at all. My priority however, is teaching you the individual and setting you up for long term future success as a front-end developer, or even a designer that wants to code.

The main thing to remember with all that in mind, is whatever you see in Figma, Sketch etc, is an impression of a website. It is not a source of truth. Treat a picture of a website — which is what you get out of these tools — as more of a reference of the look and feel you are aiming for, and make the website the actual source of truth.

Let’s start this by looking at fluid typography and space in the next lesson.