DEV Community

Kevin Powell
Kevin Powell

Posted on

Stop making responsive websites the hard way!

CSS gets a bad wrap for a number of reasons. Based on polls and surveys that I've done, one of the things people are most frustrated with is making websites responsive.

Some of the most common issues I hear are:

  • Media queries are a nightmare
  • It's difficult to find what's causing the problems
  • Too many breakpoints to worry about
  • There are too many moving parts

I recently put up a YouTube video looking at why I think many people could simplify their life by changing their approach to mobile-first, because much to my surprise, it seems like most people still do things desktop-first. A switch to a mobile-first approach would solve many of the above issues.

It's the designer's fault

In the comments section, I asked people if they prefer desktop first to tell me why they do.

The most common justification I got was:

Our designer only supplies us with desktop mockups

I understand why they start with writing their CSS to match the mocks in that situation, but I honestly don't think it's a good enough excuse.

the one good reason I did get was that they were creating web apps and admin dashboards that were only intended to be used on desktop computers, which, well, fair enough!

The reason that people starting with the desktop layout bugs me so much is that I honestly think people would have a much easier time with responsive websites if they would start mobile-first, even if they only had a desktop comp to start from.

As I talked about in my above video, we are the reasons a website is not responsive. Turn off all the CSS, and you have a responsive layout. We cause issues when we write our CSS.

Why mobile-first is a simpler approach

When I write my CSS, I don't worry about the layout at all to start. I always start with my typography.

  • font-family
  • font-sizes
  • margins on my text

With that done, you probably have a decent looking mobile website already.

Next up, you can have a large majority of your mobile site done simply by adding two more properties:

  • padding
  • background-images / background-colors

Once you've knocked that out, most of the time the mobile version of the website is pretty far along. Some components might need some detailing and some tweaking, but the majority of the work is done.

There are parts/sections/components that are more complicated on mobile

Yes, it is true that some things, such as navigation, can seem more complex. We often hide them away and have to add some JavaScript to get them to appear.

But from a layout perspective, are they more complex? Most navigation on mobile are just a <ul> with the bullets turned off and some extra spacing.

There is added complexity in how the user might interact with it, but from a layout perspective, it's very simple.

Changing your mindset

One of the hardest things to do is break out of what you are used to doing.

I really think a lot of people stick with desktop-first because we learn to create desktop sites first as static sites.

Because of that, it's just the natural starting place any time we start creating a website. But I really believe it leads to many of the issues people have with making sites responsive in the first place.

We have to override so many of the styles we already applied when we start desktop-first, rather than letting the site be naturally responsive. By changing our mindset and by starting mobile-first and adding complexity, we can:

  • simplify the process
  • write less code
  • run into less issues

Overcoming the challenges of responsive layouts

I want to show people how, if they simplify their approach, responsive layouts aren't that difficult.

To help do that, I'm launching a free course called Conquering Responsive Layouts. It's not a deep dive into anything except for responsive layouts. I've set it up as a 21-day challenge.

If you'd like to join up, the challenge is starting on April 13th. After that, the doors will be closed for a few months. So if you struggle with responsive layouts, take the challenge and learn to conquer them.

If you missed out on this round, I'll be opening the course again every few months, and it'll always be free. You can still head over to the page and sign up, and I'll notify you when it's going to relaunch

Top comments (32)

Collapse
 
ghost profile image
Ghost

I think is even simpler than that, default html and css are perfectly responsive, accessible and boring, everything you do to make it less boring has some level to "un-responsiveness" and "un-accessible" attached. We should be clear in what is our objective, is to showoff our amazing skills doing all kinds of shinny effects? or is to clearly deliver information, making the process as pleasurable as possible?, a nice 3MB 30%CPU animation may show how clever you are, but probably does nothing to make the site better, we have to let go our ego and think about the user/client, you want to showoff? make a blog, make a personal portfolio or something. Is a carousel the best way to deliver? is worth the extra code, the extra resources?, the fact that without JS becomes a mess?

Your **designers* were so preoccupied with whether they could, they
didn't stop to think if they should.*

  • Ian Malcolm (Jurassic Park)

Then as the author says, start simple and whenever you consider adding something, ask yourself how will this affect the responsiveness and accessibility of my site?, adds to the purpose of it?, is worth it?, Trying to "clean" a huge codebase is almost always harder than build clean code.

And always remember responsiveness and accessibility is in fashion now, but is far from a new concepts.

I'm not involved with the following links but the have offered me inspiration

motherfuckingwebsite.com/
bettermotherfuckingwebsite.com/

Collapse
 
devuxer profile image
Dan M 👨‍💻🎾🚘🏳️‍🌈

I love motherfuckingwebsite.com/, and I really love bettermotherfuckingwebsite.com/, but let's face it, they're text. If you can't make a pure text page responsive, you are doing it wrong. Things get a lot more challenging if you have tables, lists, cards, buttons, icons, and images. Here, not everything is readable or attractive if you just let it flow naturally and break wherever it feels like. Titles need to align properly with values. Things belonging to a group need to cluster together, not wrap from the end of row 2 to the beginning of row 3. The dev.to page I'm looking at right now has three columns in desktop mode. If I switch to responsive mode, the side columns go away and the left column moves to the bottom. Are these "shiny effects" or real functionality that makes it easier for users on larger devices to discover more features and content?

Collapse
 
ghost profile image
Ghost

Of course, having that in mind, browse normally and think what parts of it are actually adding and what is subtracting from the goal, sooner than later you'll notice how much is not only useless, is actually worsen the experience. Tables, list, "cards", buttons, icons, images and forms are easily done without any JS and responsive, just well applied CSS. Of course you can add as much eye candy you want, unless it takes away something more important, dev.to is a good example, all they have done and yet the page is very fast, works very well and doesn't eat halve my RAM nor my poor little CPU, more evidence that it can be done.

I've yet to see a carousel that actually make things better, to me are always annoying, a 5MB hero image taking the whole viewport with a button in the middle to go to the content has never made my experience better, it actually make me scroll for nothing and click for the same reason, background animations, or any animation for that matter, stock images, etc. Why would I want to wait for a photo of a coffee mug with papers in a desk or of a random office in the middle of a presentation?, the thing is that people often go straight to JS, even JS for links and static images for god sake. Rarely things are absolute, of course it may exist a case for carousels, just like the case for having an AK-47 and grenades, do I think those are most of the cases?, that when you buy a house those are the first items I purchase? would be the world a better place if more people have an AK-47 and a couple of grenades? I don't thinks so. Should we eradicate AK-47 and grenades because nobody needs them? I don't think so either. I would eradicate JS carousels tho :)

And in fact all of the "shinny effects" you mentioned can be done with CSS, just good old CSS. You can actually do a lot with flexboxes and grids nowadays and you can always use media queries to depend on the viewport size, I hate them, but you can. Of course you may have to make an extra effort and be more clever but the same had to be done with the goto idiom, of course it helped to make some stuff but it wasn't worth the cost. Using a lot of JS may feel more great, powerful and awesome than CSS but we are working to make good things not to boost our ego, well..., we shouldn't.

Thread Thread
 
devuxer profile image
Dan M 👨‍💻🎾🚘🏳️‍🌈 • Edited

I definitely agree that most layout can and should be done with plain HTML and CSS, and I also dislike obnoxiously large hero images and carousels. Gimmicks are bad, but features that empower users are good, and some of these features are challenging to make responsive because you can't just rely on the natural way things flow on a page. This doesn't mean you can't solve these problems with CSS. You should! It's just not always going to be easy.

Collapse
 
schwarttzy profile image
Eric Schwarz

Real responsiveness begins with using EM's, never ever using PX or REM. Understanding how many letters per-line wanted, 55-85 is the only acceptable number of letters per line. Mobile first. Then set break over points at 40em on body for desktop. And final trick to bring it all home is, @media min-width 60em body font: normal 1.13563vw, line-height: 1.25em

Otherwise I'd suggest that you are not even in the ballpark.

Collapse
 
kevinpowell profile image
Kevin Powell

Also, for line-height, you don't need the unit. A unitless line-height is effectively the same as setting it as em. Not a big deal, but can save you a few characters here and there (I'd also suggest a bigger line-height than that, it seems very tight for body text).

Collapse
 
schwarttzy profile image
Eric Schwarz

No there are not accessibility issues if you're doing it right. The nicely done em breakpoints work just fine. REM is the worst thing that can be used in CSS, it defeats the point of em.

Thread Thread
 
koichadev profile image
Khoi Hoang

If I understood it correctly. The EM is related to the parent element. If you have let's say 3-4 parents and all of the parent element have different EM unit for the font size. If we have one child element which is inside the 4th element (parent element). Using EM will be nightmare to have control over the font size. Isn't it just better to stick with REM unit in regards to the responsiveness?

Thread Thread
 
schwarttzy profile image
Eric Schwarz • Edited

Not a nightmare at all, super easy, barely an inconvenience. If the code has 4 em modifiers deep the code isn't written well, should have at most 3. How is grabbing the root font-size that the browser decided upon going to be responsive? Side note, I factor in the browser selected font-size from the beginning. So if the person wants the font bigger it displays bigger and same for smaller.

Thread Thread
 
koichadev profile image
Khoi Hoang

Yes, we should have at most 3. I just made up an arbitrary number, but if it's not 3, who knows if someone uses 4-6 or something if we have to take over some other developer who made the code. Just something to be aware I guess? 🤔

I guess using a default browser unit that has 16px is a good starting point? You could, of course, use 20px as a starting point for your REM, but I don't see any issues using the 16px = 1 REM.

Just trying to understand and learn how other developers like you are anti REM (not trying to be offensive here).

Thread Thread
 
schwarttzy profile image
Eric Schwarz • Edited

Not offended.

Nothing really changes if you are 15 em's size changes deep, just .8em to go 20% small or 1.2em to be 20% bigger.

Correct me if I'm wrong, but REM was developed so that when you had 30 em's of size changes you could dump all of those em changes and get the root em.

Collapse
 
schwarttzy profile image
Eric Schwarz

Why don't you give my website a try schwarttzy.com/ Hold "ctrl" and press "-" or "+" a bunch of time the breakpoints work just fine. The font doesn't become unreadable at 8K. Zooming on phones works just fine.

Thread Thread
 
kevinpowell profile image
Kevin Powell

When I zoom in and out, the font-size doesn't change, which tends to be the issue with setting fonts with VW. In general, someone's going to zoom because they find the text too small.

I have a 27" monitor, but my browser is never the full size. When I first visited, the font-size was actually really small for me, with the small text under the image on the right pretty much unreadable. If I went full-screen, it was nice and big and very nice, but I think most people would zoom in before adjusting the width of the browser to change the font-size. (if I made my window a little smaller, it seems to hit a breakpoint and the fonts got a little bigger, which helped).

Must say, the line-height was great though, definitely wrong on that front.

You might be really interested in using clamp() in setting sizes. Allows for a minimum, maximum, and "ideal". Browser support isn't perfect yet, but it's getting better!

Thread Thread
 
schwarttzy profile image
Eric Schwarz

Any chance I could get a screenshot? I never use my browser except in full screen. I do all my work from a small laptop. I bet if I added in minium px to the break over point I should fix the small font issue.

Collapse
 
kevinpowell profile image
Kevin Powell

I'd strongly suggest not having font-sizes set using vw. There are a accessibility issues. If someone zooms in, your nicely done em breakpoints, they'll all function properly if someone zooms in or out. On most browsers, the font-sizes will not scale properly though, and it'll break a lot of the hard work you did. I'd stick with rem.

You could also set line-lengths with ch units, which is the width of the 0 character. So if you set p { max-width: 60ch` } it would be approx. 60 characters wide maximum.

Collapse
 
jackkeller profile image
Jack Keller

I have had much better results long term using REM, of course, EM is great too. If you're using EM you just need to ensure that you plan ahead for nesting.

Collapse
 
ashbryant profile image
Ash Bryant

I like the idea of mobile first, really I do. But clients on the whole don't care what it looks like on a mobile first. They want to see it on a desktop. Perhaps as that shows off the design or their brand more?

It's really hard to change that mindset as they tend to be using a desktop device while communicating with you on the design and see it on that device.

Perhaps I haven't got the right clients or have not learnt how to change their habits? But at the end of the day I'm a freelancer that needs to get paid so building for desktop first is still something I just have to do.

Collapse
 
koichadev profile image
Khoi Hoang

Try to give them numbers of statistic of how many users use phone to browse on the internet today. If I'm not mistaking, it's 60% phone users and 40% desktop or something. I don't have any sources to confirm, but if you can find the source as an evidence to your client. They will rethink their view I believe

Collapse
 
lynnewritescode profile image
Lynne Finnigan

100% agree, I don't understand why people make this harder than it needs to be. Mobile designs or not, you will still need to make it work on mobile, so why not start there and take an additive approach.

Collapse
 
qwertydude profile image
Chris Howard

I was slow to come around to the idea of mobile first, and, to be honest... still struggle to discipline myself to it.

However, the simplest, most obvious reason for mobile first now is... that's quite often the platform that will provide the majority of you traffic. I've seen that change in traffic with many of the sites I developed over the past decade.

As one continuously frustrated by mobile sites that are poor cousins of their desktop equivalent... please do get it right with mobile first.

Collapse
 
mjcoder profile image
Mohammad Javed

I can relate to this, I use to build desktop first and then work my way down in screen sizes since I've adopted mobile-first I'm writing less CSS and with a few media queries, everything works like a dream. Mobile-first all the way. 💯

Collapse
 
marcellahaller profile image
marcellahaller

Thanks. The mobile-first approach is worth talking more about because it really solves many of the problems associated with responsive web design. This article gapsystudio.com/blog/what-is-respo... also talks about the benefits of responsive web design, which really prove the benefits of this approach.

Collapse
 
33nano profile image
Manyong'oments

Amazing post. The mobile first approach doesn't sound at all painful, considering more people in the world have smart phones as opposed to laptops or desktop computers. This is definitely a better way of building sites and easier on the mind.

Collapse
 
bergamin profile image
Guilherme Taffarel Bergamin • Edited

I'm kind of new at frontend development, but my issue usually had been the decision makers deciding that too many devices lead to longer testing times, leading to a longer time to deliver the product. This is an issue commonly found in applications for the internal public (the client of the product is the company itself and not the company's client), but not exclusive to it.

So you have a technical team showing all the advantages of something as powerful as Angular to people who are used to (and are fond of) writing Java code mixed with HTML and JavaScript in a JSP page.

They will look at all that sorcery Angular does, won't understand it and won't believe it actually doesn't take that much more time to make it responsive.

Now, if I could decide how to deal with this, wouldn't go desktop-first or mobile-first. I would go both together, but with more attention to the mobile side because a smaller screen is easier to break.

Build both workflows together and it will lower the chance for a feature having to be removed from mobile because "it doesn't fit the screen".

I don't believe in mobile web apps being less powerful than their desktop counterparts.

Collapse
 
vallerydelexy profile image
vallerydelexy

yeah, if only people apreciate mobile mockup as much as they did on desktops

Collapse
 
koichadev profile image
Khoi Hoang

Thank you for this gold insight. I must admit, I am one of the desktop first and mobile after. I am going to start and apply from now on mobile first and desktop last

Collapse
 
christianclassen profile image
ChristianClassen

Hi Kevin, please create another course / deep dive on Scrimba. Had the best learning experience with your Responsive Web Design Boot camp there!

Collapse
 
lyltqgoqaiqw5ke profile image
Александр

That's true what you said, Kevin.

Collapse
 
bezpiecznyvpn profile image
Pawel Sekuratywny

I like a lot of your points

Collapse
 
dantefrank profile image
David Dante Frank

I'm really new to frontend web design and would really love to learn a lot as I dive in. Hope this is for me