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-familyfont-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
Latest comments (30)
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.
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.
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. 💯
I like a lot of your points
Hi Kevin, please create another course / deep dive on Scrimba. Had the best learning experience with your Responsive Web Design Boot camp there!
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
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.
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.
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.
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.
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).
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.
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!
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.
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.
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?
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.
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).
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.
I'd strongly suggest not having font-sizes set using
vw. There are a accessibility issues. If someone zooms in, your nicely doneembreakpoints, 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 withrem.You could also set line-lengths with
chunits, which is the width of the 0 character. So if you set p { max-width: 60ch` } it would be approx. 60 characters wide maximum.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.
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