Lesson 2, pt. II | Responsive Design Fundamentals

Here is more theory to add to learning about Responsive Design. You won’t be seeing me use any particular software to design layouts, but I’ll be going through some new their like understanding media queries and using fluid grids. I’ll also be revisiting a concept from my previous lessons: Creating breakpoints.

I’ll start with understanding media queries, which are important part of responsive design as they allow you to write styles that respond to changes in things like screen size or orientation.

Through media declarations, CSS had allowed us to filter style application by media type for quite some time now. In the past, we have been able to define which styles apply to screen devices, projectors, printers, and handheld devices through some pretty basic syntax.

While these capabilities were extremely handy in making sure that you could write separate style sheets for screen and print, they never really realized their ultimate goal of defining multiple device types. Mobile manufacturers for the most part, shunned the handheld media type due to its limited use and their desire to give users the full web experience. That left a huge gap, in terms of a designer’s ability to write styles that changed based on the type of device being used. To fill that gap, media queries were created to allow designers to extend the media declarations to include various media properties when filtering style application.

This is actually really useful, as it allows designers to control styling based on factors such as screen size, orientation, or color, which is far more flexible than simply defining a device type.

Taking a look at the syntax and how it works, media queries contain a media type and one or more expressions. These expressions contain media features, which are then evaluated and used to determine whether styles are applied or not. Keywords such as “and,” “not,” or “only,” help you refine exactly when styles are applied.

“Not” negates the expressions that follow it and applies the styles only if the conditions that follow are not met.”Only” can be used to detect for media query support, as older user agents that don’t support them will ignore any media declarations that being with “only”. The “and” keyword allow you to join expressions together, further filtering when styles will applied.

You can also comma-separate a list of media queries, which is very much treated like the “or” logical operator.

In the case above, if one of the expressions returns true, the entire list is applied.

We also have a very divers group of media features to test for:

As you can see, some of the features also accept a minimum or a maximum prefix. This allows much more flexibility, as you can check for a minimum height or a maximum width instead of a fixed value.

After this crash course about media queries, I’m going to take a closer look at how they’re implemented in a responsive design workflow. I’ll start by exploring the concept of a breakpoint, which I’ve gone over briefly in a previous lesson. First off, a breakpoint indicates the moment your layout switches from one layout to another, and is usually triggered by the width of the screen.

Now, when I used the Sketch application in my lesson Learn Sketch: The Basics, I did indeed go through how to design layouts for different screen sizes. Each of those design layouts represented different breakpoints I wanted for the website.

Though I created four different layouts for four different screen sizes, many layouts are based on the typical screen sizes for smartphones, tablets and desktop devices. While many layouts will have more than these three basic breakpoints, almost all responsive designs will feature some combination of those three screen size ranges. This means that one of the first things that you need to do when planning a responsive design is define the breakpoints for your layout.

In the below image, you’ll see a list of the three most common breakpoints:

Mobile styles will target any screen smaller than 480 px wide, while tablet styles will usually target screens between 481 and 768 px. Desktop styles, on the other hand, will target any screen wider than 768 px. Obviously, all tablets and smartphones aren’t the same size, so you’ll need to determine which range of screen widths you want to support.

Now, I’ll go through some of the syntax begin used here to explain how breakpoints are set. First note that each of the media queries uses the “only” keyword, which hides the styles from older non-conforming user agents. Because of this, you will want to have a set of default styles to fall back on. The “screen” media types ensure that the styles apply to screen-based devices. The mobile media query uses the “maximum-width” media property to restrict styles to screens under 481 px, which should target the majority of smartphone devices.

The tablet media query uses slightly longer syntax, by combining both a minimum and a maximum-width media property to define a specific range of screen sizes. Essentially, this targets any screens between 481 to 768 px.

Note that the minimum-width value is one pixel over the smartphone query. You want to make sure there is no overlap as you plan your breakpoints, which could case some cascading issues within your styles.

Notice that all three of the media queries are suing the width property with a minimum or a maximum prefix.

It is also becoming more popular among responsive designers to set breakpoints using ems instead of pixels. By using ems, the width of the screen is set relative to the device’s font size.

Above for example, we could change this media query from px to ems by dividing the width of 480 px by 16 px and setting that to the resulting 30 ems. Since the average device font size is 16 px, this is usually a good place to start from.

While this requires us to do a little math on the front end, we now have a responsive design that responds not only to the screen’s width but also user’s zooming as well.

For this portion of lesson two, I’m going to end with discussing fluid grids. One of the most famous observations about responsive design is that it’s becoming more and more important to think of your content like water. I needs to have the ability to flow into whatever container it’s viewed on.

Of you limit yourself to creating fixed layouts for each of your breakpoints, you’re ignoring the wide variety of screen sizes within each range. One of the best ways to make sure your content works, regardless of the screens being viewed on, is to use a fluid layout so that your content can flex and resize within each of your set breakpoints.

Creating separate fluid layouts for each breakpoint create considerably more work than crafting a single fluid layout or separate fixed layouts. For this reason, many designers have adopted the use of fluid grids to make crafting multiple layouts faster and more precise. Grid systems are a fantastic way of creating structured, properly proportioned layouts that have been used by designers for decades across multiple disciplines. For a web design, grids are typically defined as a number of columns and gutters that are then used by the designer to establish the widths of page elements and regions.

The exact number of columns and their base width is typically up to the designer, and is usually related to a default font size, ideal ratio or an ideal screen width. Although the most popular is currently 960 pixels, many designers are moving to grids based off of larger ideal screen sizes, such as a thousand pixels.

Once the grid is established, page elements are mapped to grid coordinates and values are assigned based on where they fit within the grid.

Once the framework is built, creating the actual layout becomes fairly simple: based on the desired layout, you simply add the appropriate classes to the appropriate page element. If your design is relatively simple and unlikely to change frequently, it might be more efficient to simply create layouts for each breakpoint that’s tailored for specific screen ranges. If your layouts are more complex or have a wide range of variations in terms of page types, it’s probably worth it took the time to craft a framework around your site’s specific needs.

If you simply don’t have the time to construct your own fluid grid system or feel that your technical skills aren’t quite at that level yet, I’m happy to tell you that there are a multitude of existing frameworks that you can download and use within your own projects.

This frameworks range from the very simple layout-only styles to entire boilerplates that come with a mixture of HTML, CSS and JavaScript that provide a full framework for site development.

Before I end this, below is a list of some downsides to using fluid grids:

As shown, the styles are heavily class-based and usually use non-semantic class names that can clutter up your HTML. Some require specific containing and clearing elements that may force you to include additional markup to your HTML as well. Most of these frameworks are fairly large in size, too.

Whether you use an existing framework or build your own, it’s certainly worth your time to download and explore a few of them just to see how different developers approach building fluid grids.