Breaking News

How to Design a Mobile-Friendly Responsive Website in CSS



With so many people in the world using smartphones to surf the web, more and more webmasters are looking for ways in which they can make their websites mobile-friendly. This usually means modifying their sites for the smaller screen size found on such devices, either by providing a separate page that can be viewed comfortably there, or, more commonly, making their websites automatically adapt by shrinking things and moving stuff around. The latter method, often referred to as "responsive web design", is described in this tutorial series.
Image result for How to Design a Mobile-Friendly Responsive Website in CSS

Prerequisites

Since this tutorial deals with the changes you need to make to your website's low level code, you will need to know some HTML and CSS. You do not need to be an expert or anything like that, but some knowledge is necessary, otherwise this tutorial will be incomprehensible to you.
Incidentally, if you are here because you thought this article is about designing a website from scratch, please read How to Create a Website instead.

Responsive Web Design

In responsive design, we will present the same web page that desktop or laptop computer users see to your mobile audience. Only the Cascading Style Sheets, or CSS, will be different. That is, browsers on desktop/laptop computers will render the page using one set of CSS instructions, while those on mobile phones another.
This method of working not only saves you the labour of creating a different set of pages for each type of user, but also the hassle of maintaining those 2 sets over the years, trying to keep them in sync.

Overcoming the Mobile Device's Defaults: Viewport

For the purpose of this article, to avoid having to qualify everything I say, making things even more wordy than it needs to be, I will use the following shorthand. When I say either "desktop" or "computer" here, I mean a desktop or laptop computer, and not a smartphone or tablet (even though the latter two are actually computers too). And when I say a "mobile device", I mean a smartphone, a tablet with a small screen, and the like, and not a laptop computer (even though the latter is also portable). Without this shorthand, the article is going to be even more difficult to read than it already is, with multiple sentences just to explain what I mean when I say these terms. I also tend to use "smartphone" synonymously with "mobile device" here, so that the article doesn't sound too monotonous.
The browsers of modern smartphones are written with the knowledge that websites are traditionally designed for computer monitors. As such, it adapts by pretending to the website that it has a computer-sized screen and scaling everything to fit in it. For example, Safari on the iPhone 5 pretends that it has a screen width of 980 pixels by default, even though its real size is 320 pixels (in portrait mode). So if you were to design a website with a fixed width of (say) 730 pixels, its entire width will fit into your mobile phone's screen, even though the latter isn't that wide. The browser accomplishes this by shrinking your website so that everything becomes really small. If the user needs to read anything, they will have to zoom in the relevant portions. You can see this effect by going to the fixed width demo page with your smartphone. That particular page has a fixed width of 730 pixels, and is deliberately designed not to adapt to your use of a mobile phone.
Since this default of pretending that the device has a width of 980 pixels and automatically scaling content defeats our attempt to manually create a comfortable experience for mobile users, we have to override it before we can do anything meaningful. To do this, add the following HTML tag to the <HEAD> section of your web page:
<meta name="viewport" content="width=device-width, initial-scale=1">
The viewport meta tag above instructs the browser to use the actual device width with a scaling factor of 1. That is, it is not to pretend that it has some other width, nor is it to scale the content so that it fits into the existing window. Everything is to be used as-is. This instruction makes mobile browsers behave exactly like their desktop counterpart.
If you want to be future-proof, you will theoretically need to add the equivalent CSS code to your style sheet.
@viewport {
  width: device-width ;
  zoom: 1.0 ;
}
The above is the method sanctioned in the proposed CSS standards (ie, it's not actually been ratified yet). Since things like width and how a web page is presented are really style rules, they rightly belong to the style sheet instead of a meta tag in the HTML. Unfortunately, at the time I write this, no web browser actually implements it out-of-the-box. Microsoft and Google have experimental code in their browsers that support it, but it needs to be explicitly enabled by the end user.
If you want to test it in Internet Explorer 10, 11 and Microsoft Edge, because you have enabled the facility in your preferences, you should also add the following. (The zoom property has not yet been implemented.)
@-ms-viewport {
  width: device-width ;
}


The "-something-" prefix (eg, "-ms-" for Microsoft, "-webkit-" for Google, "-moz-" for Mozilla, etc) is the method used by browser vendors to add support for experimental things that have not yet been officially added to the standards. They do this because if they add, say, @viewport prematurely, using the pre-standards method still under discussion and negotiation, and the final standard eventually ends up with a different meaning for those properties, then the websites that depended on the pre-standards way of writing @viewport will break. This leads to an unholy mess where the browser vendors have to decide how to interpret the rules on a website, since some sites will rely on the pre-standard semantics while others the official one. And webmasters will not be able to solve the problem either, by coding things one way or the other, since they can't control whether their visitors use a pre-standards browser or a post-standards one. The solution is therefore to offer a prefixed version, and to only enable the one without a prefix when the standards are settled.
In any case, since the CSS method is not yet supported by any browser by default at the time I write this, and it's not even officially a standard yet, it's up to you whether you want to add it to your style sheet. If you do, you should keep up-to-date when it's finally implemented in case there are changes to how it is specified.

The Key that Unlocks a Responsive Design in CSS: Media Queries

Now that we have got the mobile phone's browser to refrain from resizing things behind our back, we have to adapt to its small screen manually. While this seems like a step backward, it actually allows us to do things in a more appropriate way than the phone's automated facility: for example, we can resize the things that can be resized (eg, images), while leaving alone others that shouldn't be resized (like the words). To make space for this, we can send elements that are not so crucial to the bottom of the screen. For example, if you were to read any article on  including this one, on a mobile phone, you will find that my navigation menu (ie, the list of buttons) that is normally in the left column in a desktop browser, is positioned at the bottom of the page on a smartphone. I figured that since the user is on this page, his/her primary purpose is to read the article. As such, I put the article at the top so that visitors can get to it immediately.
To accomplish magic like this, we need some way to detect the screen size. Modern browsers provide this facility in the form of a "media query".
A media query in a style sheet looks something like this:
@media screen and (max-width:320px) {
  /* CSS for screens that are 320 pixels or less will be put in this section */
}
Any CSS enclosed within the curly brackets of that "@media screen and (max-width:320px)" test will only apply to screens that have a maximum width of 320 pixels. You are, of course, not restricted to testing for a width of 320 pixels. The latter is merely a figure I picked for this example. You can test for min-width and max-width of any size. You can even test for range of sizes as well, such as in the following code.
@media screen and (min-width:320px) and (max-width:640px) {
  /* for screens that are at least 320 pixels wide but less than or equal to 640 pixels wide */
}
CSS rules that are not enclosed within a "@media" section apply to everyone. And code that is enclosed within a specific "@media" section will only be used when the conditions of the query are met. If you have multiple conditions that must be met simultaneously, connect them with "and" as in the examples given. You can have multiple media query blocks, each of which will only be applied when the conditions for that block are met.


/* code that is here, until the first @media block, will apply to any screen size */
#somethingorother {
  width: 800px ;
}

@media screen and (max-width: 320px) {
  /* comes into effect for screens less than or equal to 320 pixels */
  #somethingorother {
    width: 120px ;
  }
}
@media screen and (min-width: 321px) and (max-width: 480px) {
  /* comes into effect for screens between 321 and 480 pixels (inclusive) */
  #somethingorother {
    width: 320px ;
  }
}
@media screen and (min-width: 481px) {
  /* comes into effect for screens larger than or equal to 481 pixels */
  #somethingorother {
    width: 480px ;
  }
}

/* code that is here will apply to any screen size */
Note that the above is just an example meant to illustrate the use of multiple blocks of media queries. My choice of the numbers used there is arbitrary, so don't spend time puzzling over them.
You can also put your media queries in the <link> element itself, so that an entire stylesheet is only applied when that particular set of conditions is met. For example, the following loads 3 style sheets, one supposedly for mobile devices in portrait mode, another for their landscape mode, and the final for desktop and laptop computers.
<link rel="stylesheet" type="text/css" media="screen and (max-width: 360px)" href="portrait.css">
<link rel="stylesheet" type="text/css" media="screen and (min-width: 361px) and (max-width: 480px)" href="landscape.css">
<link rel="stylesheet" type="text/css" media="screen and (min-width: 481px)" href="desktop.css">
This allows you to cleanly separate your code for different screen resolutions into different files, if that is what you want. Once again, note that the point of the example above is to demonstrate the use of media queries in <link> tags. The numbers are arbitrarily selected.

Testing for Portrait and Landscape Mode with Media Queries

Instead of using specific resolutions to figure out if a device is in the portrait or landscape mode, you can also use the condition "orientation: portrait" and "orientation: landscape".
@media screen and (orientation:portrait) {
  /* ... */
}
@media screen and (orientation: landscape) {
  /* ... */
}
I tend not to use these since I find that knowing the number of pixels available more useful than just figuring out the orientation of the device. But the facility is available if you need to use it.

Other Useful Features in Media Queries

Apart from the above, you can also insert tests for min-height (ie, minimum height), max-height (maximum height), width and height.
In addition, you can start the media query with "only", as in the following snippet:
@media only screen and (max-width: 480px) {
  /* ... */
}
Very old browsers that don't understand the modern media queries syntax will think that "only" is a type of device (like "screen" or "print" or "speech"). And since they think that the rules in the block are meant for devices classified as "only", they will not follow them. Modern browsers, on the other hand, ignore the word "only" (by design), so this conditional test is useful if you need to guard against old browsers parsing your mobile-only rules and applying them even on a desktop computer.
If you want to use CSS for all situations except when certain conditions are met, you can use "not" before your condition, such as in the following example.
@media not (max-width: 639px) {
/* CSS rules for any device that is wider than 639 pixels */
}
(Note that since I didn't specify "screen" in the example above, it implies "all" which means all devices.)
Be warned though, "not" is treated like "only" in very old browsers. That is, it will interpreted as a device type and therefore the styles in the block that follows will be not be applied.


Mobile Screen Resolutions / Widths

Here is a list of the browser screen widths of some commonly-used mobile devices. The list is not exhaustive, since new brands and models are released all the time. However, the list is enough to give you an idea of the kinds of sizes that you need to accomodate.
  • 240 pixels (old Android portrait mode)
  • 320 pixels (iPhone 3 to 5 and iPhone SE portrait mode)
  • 375 pixels (iPhone 6, 6s, 7, 8 and X portrait)
  • 384 pixels (Android Nexus portrait)
  • 414 pixels (iPhone 6 Plus, 6s Plus, 7 Plus and 8 Plus portrait)
  • 480 pixels (iPhone 3 and 4 landscape mode)
  • 568 pixels (iPhone 5 and iPhone SE landscape)
  • 600 pixels (Android Nexus landscape, Kindle portrait)
  • 667 pixels (iPhone 6, 7 and 8 landscape)
  • 736 pixels (iPhone 6 Plus, 7 Plus and 8 Plus landscape)
  • 768 pixels (iPad portrait)
  • 812 pixels (iPhone X landscape)
  • 1024 pixels (iPad landscape)
I treat all screen widths above 629 pixels as being sufficient for my 2 column layout. Resolutions below that get a single column, with the navigation column (the left column) pushed to the bottom of the screen. You can see the effect of my mobile CSS rules even if you are on a desktop: simply resize your browser window on this very article you are reading. If you shrink the width smaller than 629 pixels, you will get the single column that the mobile users see.


Note that you do not have to follow my system of partitioning the CSS at 629 pixels. That's just the figure I used because it seems to work fine for content. In fact, if I remember correctly, I saw a site that switched to a mobile layout only at 480 pixels, while another switched to different layouts depending on whether the screen had 940, 640 or 520 pixels on its horizontal axis. I recommend that you do not blindly follow other sites' size conditions: use a number that suits your content, testing and adjusting it accordingly.

Compatibility with Web Browsers

The media queries facility that allows us to test for screen size is a latecomer to the web browser scene. That is to say, CSS had already existed for years before the standard included the means to conditionally apply certain rules to certain screen sizes. As such, very old browsers do not support these features.
Where smartphones are concerned, as far as I know, media queries are only supported on Android browsers beginning with version 2.1, on iPhones's Safari 3.2 and above, Blackberry 7 and later, Opera Mobile 12 and later, Opera Mini 8, and Internet Explorer ("IE") mobile 10 and above.
On the desktop/laptop browsers front, support appears to have started with IE 9, Firefox 3.5, Safari 4 and Chrome 4. Since Microsoft Edge was originally based on IE 11's code, it has always had media queries support.
In view of the above, how safe is it to use media queries on your site?
  • A lot depends on your site's demographics. For example, if your site has many people using phones with IE mobile 9 and earlier, you will probably want to support them.


    This is not impossible, since early versions of IE allow the use of conditional comments, where you can include rules that will only be rendered by them and not other browsers. As such, it's possible to detect those browsers without resorting to media queries.
    Alternatively, you can use JavaScript to detect the screen size and adjust your style sheet accordingly. There are even free JavaScripts floating around the Internet that implement media queries on early IE versions, although I have not tried any of them and therefore cannot vouch for them.
  • If your site has very few visitors using such old mobile browsers, then you have to decide whether or not you want to bother creating a solution specially for them. You may find that the time and effort you need to expend is disproportionate to the number of people that actually benefit from it. And that number will only decrease with time. As such, you may want to just let such users view your site using the default style sheet (which was what everyone would have seen anyway, before you suddenly decided to create a mobile-friendly one).

No comments