When viewing a website on different devices, we of course expect it to resize to the available device width automatically with no loss of experience; unfortunately, not every site does this quite the right way or successfully!
To understand why this is important, let's assume we operate a desktop version of our site (one in the 1280+ group in this screenshot), and a mobile equivalent from the 418-768 group:
The first stage in making our site responsive is to add the viewport directive; without it, we are likely to end up with a similar effect to this when resizing our sites:
See what I mean? It looks awful—text is cut off, we would have to swipe to the right...ugh! In stark contrast, adding one line of code can have a dramatic effect:
Our example uses the Google Chrome set to emulate an iPhone 6 Plus. The code needed to restore sanity to our example can be added to the <head> of our code:
<meta name="viewport" content="width=device-width, initial-scale=1">
Once set, we can immediately see the difference. Granted, our demo isn’t going to win any style awards, but then it wasn't the aim! It does, however, show that the text has been reduced in size to fit the screen, we have a proper border around the text—it all looks more pleasing as a display.
The content property in this directive supports using any one of a number of different values:
|
Property |
Description |
|
|
The width of the virtual viewport of the device. |
|
|
The physical width of the device's screen. |
|
|
The height of the virtual viewport of the device. |
|
|
The physical height of the device's screen. |
|
|
The initial zoom when visiting the page; setting 1.0 does not zoom. |
|
|
The minimum amount the visitor can zoom on the page; setting 1.0 does not zoom. |
|
|
The maximum amount the visitor can zoom on the page; setting 1.0 does not zoom. |
|
|
Allows the device to zoom in and out (yes) or remain fixed (no). |
Current versions of MS Edge don't play so well with viewport tags; it is worth noting that @-ms-viewport needs to be specified in code to ensure our viewport widths behave in the same way as other browsers.
You will notice that I italicized the word experience at the start of this section—the key point here is that in responsive design, the experience does not have to be identical across all devices; it must be useful though, and allow our visitors to interact with us as an organization. In other words, if we worked for a theater, we might limit our mobile offer to simply booking tickets, and let the main desktop site manage everything else.
This is perfectly valid; while limiting a site, mobile ticketing might be considered by some as very restrictive. The concept is still technically sound, as long as the user experience is acceptable.
It's worth noting that we could have set a specific width using width=<value>. This is great if we need a certain width to display our content; if the orientation changes from portrait (320px) to landscape (360px) for example, then the viewport's content will be automatically scaled up and down to reflect these changes. If, however, we had set a device-width as a maximum, this implies that no scaling is need and that the browser should adjust the content within it to fit.
A key part of responsive design is to make the move away from using pixel values to working with em or rem units. In our examples (and the viewport demo from earlier in this chapter), we used both pixel and rem units. Although this works well, we still have a dependency on parent elements. Instead, we should consider using an alternative for working with viewports. They are:
- vw: viewport width
- vh: viewport height
- vmax: maximum of the viewport's height and width
- vmin: minimum of the viewport's height and width
As a unit of measure, these equate to 1% of the viewport area that has been set; the beauty though is that they remove any dependency elements, and are calculated based on the current viewport size. Browser support for them is currently very good:
Source: http://caniuse.com/#search=vh
Leaving aside the slight quirks with more recent versions of Internet Explorer, this is a useful option that combines the ease of units, with the flexibility of using percentages, in our designs.
Let’s move on—we’ve introduced flexible grids and explored how setting a viewport is critical to displaying content correctly. It’s time we moved on and explore some of the benefits of incorporating a grid system into our layout, and dive into the internals of how they work as a principle in responsive design.