The building blocks of responsive design

  • Revision slug: Web/Apps/app_layout/responsive_design_building_blocks
  • Revision title: The building blocks of responsive design
  • Revision id: 452421
  • Created:
  • Creator: chrisdavidmills
  • Is current revision? No
  • Comment

Revision Content

Introduction

As web developers, it is now fairly standard practice to be called upon to create a web site/app that changes its user interface depending on the browser/device accessing the site, to provide an optimized experience. One approach to this is to create different versions of your site/app for different platforms or browsers and serve them appropriately after detecting which browser or platform is looking at your site. But this is increasingly inefficient: browser sniffing is inherently error prone, and maintaining multiple copies of your code can turn out to be a nightmare.

It is usually much better to create a single version of your code, which doesn't care about what browser or platform is accessing the site, but instead uses feature tests to find out what code features the browser supports or what the values of certain browser features are, and then adjusts the code appropriately. This tends to be termed responsive design or adaptive design, two related but different approaches (for a discussion on the differences between the two, read Responsive design versus adaptive design.)

This is much more reliable, more maintainable, and more future proof. You don't get caught in the situation of having to bring out more new site versions as more new browsers and platforms come out, and adjust code as feature support in existing browsers changes.

There are disadvantages to this type of approach as well. If the content, layout, and functionality need to change greatly for different devices, it may not be such a good approach. Also, taking an existing site and adding responsiveness to it, to make it mobile/tablet friendly, can be a lot more effort than just creating a separate mobile site or app, especially if it is a sprawling enterprise site. Read more about responsive design advantages and disadvantages.

In this article we will briefly discuss the main essential components of responsive design, with some links to further information where necessary.

Fluid grids

The best place to start is with fluid measurements for your application layout — essentially, this means using a combination of percentages and ems/rems to size your containers and text, not fixed widths such as pixels. This has a lot of advantages in that the layout will adapt to different viewport dimensions. Let's look at an example:

TBD

Media queries

Fluid grids are a great start, but you'll notice that at certain points the layout starts to break down (known as the breakpoints.) It may be just a small issue (minor breakpoint), or a major layout catastrophe (major breakpoint)! At these points you'll want to change the layout to rectify the layout problem, and this can be done using media queries.

Media queries are a CSS3 feature that allow you to selectively apply CSS depending on the results of media feature tests — for more on the basics, read Media queries.

Generally you'll have a media query for each different UI design you drew in your planning stage, to swap between the different layouts — these are the major breakpoints. Each major breakpoint will have a separate fluid layout within it. You may also have some media queries in place to fix the minor layout glitches (the minor break points.) Lets look at how this works.

In our example layout, we have a desktop layout...

TBD

We also have a mid-width hybrid layout, which is aimed at working well on tablets and narrow laptop screens...

TBD

Lastly,  we have a mobile layout...

Flexible image dimensions

Things are working pretty well now, but there are still some issues just waiting to present themselves. For a start, let's have a look at what happens when we include an <img> inside one of our fluid columns. To start with, things work out ok:

image TBD

But when the viewport width is altered to the point where the container starts to become narrower than the image, the image breaks out of the container in an unsightly manner.

image TBD

This is is actually easily fixed, with a simple line of code:

img {

  max-width: 100%;

}

Image TBD

More TBD

Responsive image techniques

Another problem that comes up more and more these days is making image weight (size in KB) responsive as well as the dimensions of the image on screen. Yes, you want the images to be contained inside the app UI whether you are using it on desktop or mobile, but you should also consider that mobile apps have much smaller viewport dimensions available than desktop apps, so you should try to give mobile devices a smaller image to download. Mobiles in general (more commonly in some parts of the world than others) are on lower bandwidth and have less memory available than desktop devices, so yes, those extra kilobytes really do count.

CSS background images

For CSS background images this is a fairly easy problem to solve. If you use the mobile first methodology, you will be creating your mobile layout inside your default CSS, before any media queries have been applied. The following is used in my example app:

TBD

The media queries then supply CSS that is only applied to the markup when the viewport is above a certain width. For example:

TBD

This means that the mobile browser is only downloading the mobile background image assets — it never downloads the desktop mobile assets because it fails the media query tests and therefore ignores the media queries.

<img>

HTML images are a more difficult proposition. There is no mechanism inherent in HTML images for serving different image file dependant on viewport size, and, due to a number of irksome browser behaviour realities, things are difficult here.

mention <picture>

list resp img techniques

SVG and other vector graphics

Resolution

Viewport

Revision Source

<h2 id="Introduction">Introduction</h2>
<p>As web developers, it is now fairly standard practice to be called upon to create a web site/app that changes its user interface depending on the browser/device accessing the site, to provide an optimized experience. One approach to this is to create different versions of your site/app for different platforms or browsers and serve them appropriately after detecting which browser or platform is looking at your site. But this is increasingly inefficient: browser sniffing is inherently error prone, and maintaining multiple copies of your code can turn out to be a nightmare.</p>
<p>It is usually much better to create a single version of your code, which doesn't care about what browser or platform is accessing the site, but instead uses feature tests to find out what code features the browser supports or what the values of certain browser features are, and then adjusts the code appropriately. This tends to be termed <strong>responsive design</strong> or <strong>adaptive design</strong>, two related but different approaches (for a discussion on the differences between the two, read <a href="/en-US/docs/Web/Apps/app_layout/Responsive_design_versus_adaptive_design" title="/en-US/docs/Web/Apps/app_layout/Responsive_design_versus_adaptive_design">Responsive design versus adaptive design</a>.)</p>
<p>This is much more reliable, more maintainable, and more future proof. You don't get caught in the situation of having to bring out more new site versions as more new browsers and platforms come out, and adjust code as feature support in existing browsers changes.</p>
<p>There are disadvantages to this type of approach as well. If the content, layout, and functionality need to change greatly for different devices, it may not be such a good approach. Also, taking an existing site and adding responsiveness to it, to make it mobile/tablet friendly, can be a lot more effort than just creating a separate mobile site or app, especially if it is a sprawling enterprise site. Read more about <a href="/en-US/docs/Web_Development/Mobile/Responsive_design" title="/en-US/docs/Web_Development/Mobile/Responsive_design">responsive design advantages and disadvantages</a>.</p>
<p>In this article we will briefly discuss the main essential components of responsive design, with some links to further information where necessary.</p>
<h2 id="Fluid_grids">Fluid grids</h2>
<p>The best place to start is with fluid measurements for your application layout — essentially, this means using a combination of percentages and ems/rems to size your containers and text, not fixed widths such as pixels. This has a lot of advantages in that the layout will adapt to different viewport dimensions. Let's look at an example:</p>
<p>TBD</p>
<h2 id="Media_queries">Media queries</h2>
<p>Fluid grids are a great start, but you'll notice that at certain points the layout starts to break down (known as the breakpoints.) It may be just a small issue (minor breakpoint), or a major layout catastrophe (major breakpoint)! At these points you'll want to change the layout to rectify the layout problem, and this can be done using media queries.</p>
<div class="note">
  <p>Media queries are a CSS3 feature that allow you to selectively apply CSS depending on the results of media feature tests — for more on the basics, read <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries">Media queries</a>.</p>
</div>
<p>Generally you'll have a media query for each different UI design you drew in your planning stage, to swap between the different layouts — these are the major breakpoints. Each major breakpoint will have a separate fluid layout within it. You may also have some media queries in place to fix the minor layout glitches (the minor break points.) Lets look at how this works.</p>
<p>In our example layout, we have a desktop layout...</p>
<p>TBD</p>
<p>We also have a mid-width hybrid layout, which is aimed at working well on tablets and narrow laptop screens...</p>
<p>TBD</p>
<p>Lastly,&nbsp; we have a mobile layout...</p>
<h2 id="Flexible_images">Flexible image dimensions</h2>
<p>Things are working pretty well now, but there are still some issues just waiting to present themselves. For a start, let's have a look at what happens when we include an <code>&lt;img&gt;</code> inside one of our fluid columns. To start with, things work out ok:</p>
<p>image TBD</p>
<p>But when the viewport width is altered to the point where the container starts to become narrower than the image, the image breaks out of the container in an unsightly manner.</p>
<p>image TBD</p>
<p>This is is actually easily fixed, with a simple line of code:</p>
<pre>
img {

  max-width: 100%;

}</pre>
<p>Image TBD</p>
<p>More TBD</p>
<h2 id="Vector_graphics_and_responsive_image_techniques">Responsive image techniques</h2>
<p>Another problem that comes up more and more these days is making image weight (size in KB) responsive as well as the dimensions of the image on screen. Yes, you want the images to be contained inside the app UI whether you are using it on desktop or mobile, but you should also consider that mobile apps have much smaller viewport dimensions available than desktop apps, so you should try to give mobile devices a smaller image to download. Mobiles in general (more commonly in some parts of the world than others) are on lower bandwidth and have less memory available than desktop devices, so yes, those extra kilobytes really do count.</p>
<h3>CSS background images</h3>
<p>For CSS background images this is a fairly easy problem to solve. If you use the <a href="/en-US/docs/Web/Apps/app_layout/Mobile_first" title="/en-US/docs/Web/Apps/app_layout/Mobile_first">mobile first</a> methodology, you will be creating your mobile layout inside your default CSS, before any media queries have been applied. The following is used in my example app:</p>
<p>TBD</p>
<p>The media queries then supply CSS that is only applied to the markup when the viewport is <strong>above</strong> a certain width. For example:</p>
<p>TBD</p>
<p>This means that the mobile browser is only downloading the mobile background image assets — it never downloads the desktop mobile assets because it fails the media query tests and therefore ignores the media queries.</p>
<h3>&lt;img&gt;</h3>
<p>HTML images are a more difficult proposition. There is no mechanism inherent in HTML images for serving different image file dependant on viewport size, and, due to a number of irksome browser behaviour realities, things are difficult here.</p>
<p>mention &lt;picture&gt;</p>
<p>list resp img techniques</p>
<h3>SVG and other vector graphics</h3>
<h2 id="Vector_graphics_and_responsive_image_techniques">Resolution</h2>
<h2 id="Viewport">Viewport</h2>
Revert to this revision