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
Top comments (30)
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?
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/
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?
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.
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.
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.
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 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.
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
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.
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'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.
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. ๐ฏ
yeah, if only people apreciate mobile mockup as much as they did on desktops