A responsive design is achieved by defining layouts for different resolutions and making each layout liquid so that transition between them is fluid as screen size changes. Naturally, taken literally, there is a problem with this principle, because there are many different screen resolutions and it would be inefficient, if not impossible, to cater to all of them. So, only standard screen resolutions for classes of devices are typically considered, and these are mobile, tablet, and desktop. The primary goal is to have a design that makes the resizing and rearrangement of its elements work well on these resolutions. The most common method for achieving this is to start by creating a layout that works well with the smallest device class, which as of time writing is the mobile- phone class, and then progressively adjust the layout (e.g., by changing size and position) for larger device classes, in this case, tablet and desktop classes.
The technique of creating a design for the smallest device first is known by the term “mobile first” and was first coined by Luke Wrobleswki. Figure 21.3 illustrates the kinds of differences in layouts that are typical between mobile, tablet, and desktop classes of devices.
Notice that all the layouts contain the same elements, which are also in the same order, and that only their sizes, shapes, and positions change. When the width of a browser displaying the desktop layout is contracted, at a specified point, the layout changes to that for the tablet, and if the contraction continues, the tablet layout changes to the mobile layout. Of course, in some cases, some elements that are present in the design for larger screens may not be in the design for smaller ones. Also, just two versions of a design may be enough: one for smaller screens and another for larger screens. Figures 21.4 and 21.5 show the wider-screen and smaller-screen versions of the same Web page. Notice the different arrangements and sizes of the design elements. Notice also that some elements are left out of the smaller version and the use of a smaller, more compact menu bar in the form of a three-line menu navigation icon (known as navicon). This icon is commonly used for all sizes of designs and further discussed in Chapter 25, where it is most relevant.
In the wider screen design, when the user clicks a menu, a dropdown menu is displayed, from which the user chooses a menu item and is taken to the corresponding page. In the smaller screen design, space limitation makes the process of getting to the information page a little longer. When the navicon is touched, the menus are displayed, and when the user touches a menu, a page is displayed that shows the menu items, from which the user then chooses one and is taken to the corresponding page.
1. Steps for Creating a Responsive Design
Irrespective of the number of layout versions used, the three main steps involved in producing a responsive design are:
- Creating the layouts for different screen sizes.
- Creating fluid media assets.
- Creating CSS rules for changing between layouts.
1.1. Creating the Layouts for Different Screen Sizes
One way the layouts for different screen sizes are created is to first sketch out, typically on a grid paper or a grid document on the screen, the rough layouts for the device classes, starting with the mobile layout and then progressing to the tablet and desktop layouts. This would involve working out the dimensions for the page, the main containing elements, the gutters between them, margins, and so on, and creating the frameworks for the desired layouts. The use of a grid is especially important, as a grid helps in the accurate determination of dimensions of elements and their placements, thereby saving time. There are several free grid systems available on the Web that can be used for the purpose. Grid systems have been discussed later.
Once the layouts are completed, the one for the mobile class is implemented first as liquid layout, using HTML and CSS rules. The layout is created in liquid layout so that it can stretch and contract with changes in the browser window’s size. At this point, although the layout stretches and contracts, any media objects it contains will usually remain fixed in size until they too are made fluid.
1.2. Creating Fluid Media Assets
Whereas text is fluid by default in browsers, in that it reflows accordingly as the browser window narrows or widens, other visual media object types, such as images, videos, and animations, expect vector graphics, are not fluid and, therefore, will be cropped once the browser window becomes too small for their dimension. Making them fluid too can be done with CSS, and there are a number of ways of doing this. One of the easiest is to specify the max-width property on the media object’s HTML element (i.e., <img> or <video>) in relative units, such as percent. For example, making the value of the property 100% will make the media object display at its full width, or the full width of its container, as well as make it scalable. However, when done in this way, the image starts resizing only when the width of the browser window becomes less than that of the image. The image will also not resize beyond its full size, even if the size of the window keeps widening.
An approach that produces a more scalable media object, which can also be used where necessary, is to express the value of the width property on the media object as a percentage of the width of the page layout. For example, assuming that the width of an image is 600px and that of the page is 1400px, then the relative width of the image is 42.85714285714286% (i.e., (600/1400) x 100), and this value is simply used for the width property. Using this approach, the image starts resizing the moment the browser window is resized and continues resizing even beyond its full width. It is usually the more preferred approach when media is within text, whereas the max- width approach is most typically used for header and “hero” images. In all cases, the height of the media object automatically resizes proportionately to the width, so that the aspect ratio is maintained to avoid stretchy or squashy appearance. To prevent an image from looking too small or too large relative to text in a design when screen size is too small or too large, the minimum and maximum widths can be specified in an absolute unit. Once all media objects have been made fluid, the next step is to define CSS rules that will resize the elements as well as rearrange them where necessary according to the screen size.
1.3. Creating CSS Rules for Changing between Layouts
The layouts displayed for specific screen sizes are specified using CSS media queries, which basically specify the points (known as breakpoints) at which certain style rules are to be applied.
1.3.1. Media Queries
A media query is created with the @media rule CSS at-rule, which takes a media type (i.e., a device type) and one or more expressions containing the features of the media type (e.g., width and height) that can be judged to be true or false. Figure 21.6 shows the basic structure of a media query.
The example basically says that if media type is a color computer screen and the maximum width of its viewport (display area) is equal to or less than 480px, then make the background color of the <body> element grey. The “and” in the query is known as a logical operator and allows for multiple expressions to be combined to form complex queries. The other operators are “not” (which specifies the negative of “and”) and “only” (which restricts a query only to the media types that support it). The “max-” in the expression is a prefix that is used before media features. The other prefix is “min-,” which means “equal to or greater than.” Although the example has only one media query, multiple media queries can be specified with a single @media at-rule, in which case, they are comma separated. Also, in addition to “screen,” other media types are supported by the at-rule, including several media features, although only a few are usually used in responsive Web design. Table 21.2 lists some common ones.
The style rules for a media query can be specified with it, as shown in the earlier example, or in separate stylesheets, in which case, the HTML <link> element is used to link to the stylesheets. Figure 21.7 shows how this is done. The first media attribute specifies the media query that says to link to the “mobile-phone.css” stylesheet and apply the styles in it only if device-width is equal to or less than 479px. The second one says to use the “tablet.css” stylesheet only if device-width is equal to or greater than 480px.
It is useful to note that width is different from device-width, which is the actual number of pixels that make up the width of a screen. In some devices, these properties are the same, while in others they are different. For example, some iPhone models have widths that are more than device-widths, due to the use of retina display technology, which allows more pixels to be packed into the space for one pixel. In relation to responsive design, it is width that is usually used, because it better determines what is displayed. The devicewidth property is typically used only when specifically targeting mobile devices.
The other method of making use of CSS rules contained in separate stylesheets is through the @import CSS at-rule. The rule allows you to import one stylesheet into another. As mentioned in relation to typefaces and fonts in Chapter 13, the rule can be included in the <head> element of an HTML document. However, it can also be used in a linked stylesheet by including it at the beginning of the stylesheet, before any other rule. For example, to import a stylesheet named “menu.css” into another stylesheet, you would include the following line:
@import url(“menu.css”);
This is done for every stylesheet to be imported. It maybe useful to know that there is no difference between linking to a stylesheet or importing it, except that some older browsers may not support the @import at-rule. A common approach is to link to an external stylesheet and then use the at-rule to import stylesheets into it.
1.3.2. Breakpoints
Before media queries can be applied, decisions have to be made about points at which to apply them. These points, as mentioned earlier, are known as breakpoints and derived in various ways. One way is to determine them based on the screen sizes of current device classes, such as mobile phone (480px and below), tablet (481-768px), and desktop (769-1232px). However, using common screen sizes does not produce a versatile enough result, in that it carries with it the need for possible constant maintenance, given that new screen sizes continually emerge and there is no way of determining what will happen in the future.
A more generally preferred approach is to determine breakpoints visually, using the behavior of content during resizing as guide. This typically involves opening the relevant mobile fluid design in a desktop browser that is capable of displaying information about its current window size. Most browsers are able to do this once you open their development tool. In Chrome, for example, the F12 key opens the tool. Once the mobile fluid layout is opened, the browser window is narrowed as much as possible and then slowly widened. As this is done, the point is looked for at which content layout changes significantly and becomes unacceptable. This point is known as “where the content breaks.” It could be, for example, the point at which whitespaces between elements become too wide, or the number of characters per line is not within 45-75 (roughly 8-10 words), or font size becomes disproportionate to the rest of content, or padding and margins of elements start to look unnatural. This point is the first breakpoint and two media queries are required to specify how the layout should change when browser window size reaches it. One query is for when window size is at the breakpoint or any size below it, and the other is for when it is any size above. Each query basically contains the rules that specify the required layout. Once the media queries are implemented, the browser is reset and the procedure is started again to look for the next breakpoint, and so on, until all breakpoints have been found.
The number of breakpoints defined depends on the nature of content. For example, some content types may require that layouts be created only for small and large screens if the same layout looks good and the content is legible on, for example, both tablets and desktops. Indeed, a layout that suits tablet display is often adequate for most desktop screens, since both devices are viewed at similar distances from the eyes. It is important to know that a wider screen is not reason enough to make a design span the full width. Content could simply be placed in the center and white space left at both sides, as illustrated in Figure 21.8. Alternatively, if content type permits, such as if there is enough text, and the screen is wide enough, more than one column could be used, meaning, for example, that at the breakpoint defined for extra-large screens, an extra column is added via media query.
Naturally, if a design is also to be displayed on much larger screens that are viewed from much greater distances, such as TV screens, then additional breakpoints certainly need to be considered. In all cases, an important factor that should not be overlooked in a responsive design is legibility, given that screen size and the distance between the eyes and the screen can readily affect it. So, it is highly likely when creating a responsive design that adjusting font size will be inevitable. Generally, the smaller the screen size, the smaller the font size that would be most suitable, given that small screens are used close to the eyes.
Where change in font size is necessary, size should be expressed in ems unit rather than in an absolute unit in order to ensure both fluidity and proportionality with the font size set for the browser by the user. In all, by basing the determination of breakpoints on content behavior, the chances of incurring the fewest breakpoints are increased and future needs for maintenance are greatly minimized. To help with this approach, there are now useful tools on the Web for finding breakpoints based on content. They typically allow you to upload the relevant page, after which the sliders provided can be used to change viewport width and height while the behavior of the content is observed for possible breakpoints. One of these tools is responsivepx.
2. Implementing Responsive Design via Flexbox
This example serves to demonstrate how a responsive design might be implemented following the steps just described and using the basic design used earlier to explain the fixed and liquid layouts. Starting with the mobile size, the design layout (i.e., the one in Figures 21.1 and 21.2) is repurposed into one for small screens. Figure 21.9 shows the repurposed mobile design, which is a liquid layout, and Figures 21.10 and 21.11 show the codes.
In the example, the body{} rule specifies the font, text color, and text alignment to use for the page; the display property makes the <body> element a flex container, and flex-direction says to stack its flex items (i.e., its children) vertically. The header, aside, article, footer{} rule specifies the background color, padding for all four edges, bottom margin, and corner roundness for the <header>, <aside>, <article>, and <footer> elements. The ul{} rule uses list- style-type to remove bullet points from the list items, padding-left to remove the default indentation to make the list not move off the center to the right, and line-height to provide enough vertical space between the items to accommodate finger-touching. The ul li a{} rule removes the underline decoration from the links, and the aside{}, arti- cle{}, and footer{} rules each specify the height of the <aside>, <article>, and <footer> elements, respectively. For the auto values, the browser uses the size of the element’s content to determine height. If you specify fixed height, content from one box may overflow into the one below. Notice that no width is specified for any element. This ensures that their widths are fluid and change with the browser’s width. On the other hand, you could specify their widths in relative units (e.g., %), in which case, just specifying the width of the <body> element is enough.
The next step in the example implementation is to find the first breakpoint for a wider screen size. To do this, the browser window is widened until the layout no longer seems right for the browser width. This point is found to be around 600px, so, one media query is created for screen sizes that are equal to or less than 599px (1px less than the point of the break) and placed at the beginning of the CSS code for the mobile layout shown earlier in Figure 21.9. This is the query that is added: @media all and (max- width: 599px) {, with the rules for the mobile layout placed between the two curly brackets, as shown in Figure 21.12.
Next, a second media query is created for screen sizes that are equal to or greater than 600px and the rules for the liquid layout for a wider screen size are placed in it, as shown in Figure 21.13. Figure 21.14 shows the result, which is the same as the one shown earlier for fixed and fluid layouts in Figures 21.1 and 21.2.
In the body{} rule in the media query, width makes the width of the <body> element (i.e., the page) 90% that of the browser window, margin aligns it 30px from top and bottom, and centers it horizontally, color specifies the text color, font-family specifies the font, and text-align centers the text. In the main{} rule, height sets the height of the <main> element and display makes it a flex container, making the <aside> and <article> elements flex items. The header, aside, article, footer{} rule sets the background color, padding, bottom margin, and corner roundness for the <header>, <aside>, <article>, and <footer> elements. In the li{} rule, display changes the <li> elements from block level to inline-level elements (removing the bullet points and displaying them on the same line) and padding puts some space between them. The ul li a{} rule removes the underline decoration from the links. The main > aside {} rule applies to the <aside> element that is a direct child of the <main> element. In it, margin-right puts some place between the element and the next one to the right, height sets its height, flex says to stretch it at one time the rate of the other flex items (in this case the <article> element), and order places it first. The main > article {} rule applies to the <article> element that is a direct child of the <main> element. It sets the height of the element, says to stretch it at four times the rate of other flex items (i.e., the <aside> element), and places it second. The “>“ selector is one of the selectors introduced in Chapter 8.
Next, repeating the procedure for finding the next breakpoint, it is found to be around 1200px. However, because the layout created for the 600px breakpoint also looks all right for this breakpoint when stretched, no change is deemed necessary to the layout. It is also found that there is no need for the layout to stretch beyond this point, irrespective of how much wider the screen becomes, as this will only make the content difficult to read. So, to stop the layout from continuing to stretch once it gets to 1200px, a declaration is added to the body{} rule to specify the maximum width for the <body> element, using the max-width property, thus: max-width: 1200px;. The result is that a responsive design is produced in which when the browser window is 599px wide or less, the mobile liquid layout is displayed, and as the browser widens, the layout stretches until the browser window’s width gets to 600px, at which point, the layout changes and then continues to stretch until the browser window’s width gets to 1200px, at which point the layout no longer stretches because the <body> element has reached the specified maximum width.
3. Implementing Responsive Design via Grid
This example serves to demonstrate how the responsive design just implemented using flexbox can be implemented using grid layout. Figures 21.15, 21.16, and 21.17 show the codes.
In Figure 21.16, the @media at-rule says, if the width of the viewport is 599px or less, to apply the rules within the curly brackets for all media (i.e., screen and printer). The #grid{} rule targets the element of id=“grid,” sets the font and content alignment, makes it a grid container and its children grid items, and creates a 4-column-1-row grid with a row gap of 5px. The header, aside, article, footer{} rule specifies background color, padding, and corner radius for the <header>, <aside>, <article>, and <footer> elements; the ul{} rule removes the bullet points and indentation from the list items and increases the line spacing; and the ul li a{} rule removes the underline decoration from the menu links.
In Figure 21.17, the @media at-rule says, if the width of the viewport is 600px or more, to apply the rules within the curly brackets for all media (i.e., screen and printer). The #grid{} rule targets the element of id=“grid,” and sets the width, height, font to use, text color, and content alignment; display makes it a grid container and its children grid items; grid-template-areas defines six grid areas (i.e., two columns and three rows) in it; grid-template-columns defines the sizes for the columns; grid-template-rows defines the sizes for the rows; grid-column- gap defines the gaps between the columns; and grid-row- gap defines the gaps between the rows. The #grid header{}, #grid aside{}, #grid arti- cle{}, and #grid footer{} rules place the <header>, <aside>, <article>, and <footer> elements (i.e., grid items) in the specified grid areas. The header, aside, article, footer{} rule specifies background color, padding, and corner radius for the same elements; the li{} rule changes the <li> elements from block level to inline elements to align them horizontally; and the ul li a {} rule removes the underline decoration from the link text.
Source: Sklar David (2016), HTML: A Gentle Introduction to the Web’s Most Popular Language, O’Reilly Media; 1st edition.