Skip to main content

Common Responsive Design Layout Issues (and how to avoid them)

May 20 '16

On responsive websites, the "in-between" viewport widths tend to be far more error-prone than those of full-size desktops or smartphones. All too often we consider the beautiful 1400px desktop layout and the single-column mobile layout in our responsive design, but fail to account for what the site will look like just one pixel above the smallest breakpoint.

The following common design patterns pose this problem - but can be avoided.

Issue #1: Over-reliance on fixed heights

It's very easy to fall into the trap of laying out our content in rows, assuming that (as in our Photoshop mockups) we know exactly how wide the row will be and what content will appear within it. One common example (shown below) is a row with a solid background color, in which a full-height image floats one direction while text floats the opposite direction alongside it.

The problem here is simple geometry. Assuming that we keep our image proportionate, it is going to shrink in height as it gets narrower. The text, on the other hand, will break to more lines as it gets narrower, meaning the text will quickly become taller than the image, leaving a strange space below the image. This particular example breaks as wide as 1015px.

An image next to text looking correct at full desktop width.
At 1200px, the image is taller than the text and subsequently takes up the entire height of the container as designed.
An image next to text looking incorrect at an intermediate width.
As the viewport narrows, the image shrinks proportionately and the text breaks to more lines, meaning that the image is now shorter than the text and does not reach the bottom of the container. This particular example breaks at a width as wide as 1015px.
An image above text looking correct at the narrowest breakpoint.
At a narrow breakpoint, the image stacks on top of the text and looks correct once more.

You can view this example in browser or edit the source on Codepen.

What do I do about it?

Designers: I would encourage simply not doing this. Omitting the background color keeps this from looking strange when the text becomes taller than the image in a responsive design. If you need to separate multiple rows with this same pattern, consider using a horizontal rule instead.

If you are stuck with this situation as a front-end developer, there are several tactics you can employ. To a certain extent, you can make the font smaller as the viewport narrows, as long as you maintain legibility. Additionally, you can change the aspect ratio of the image in several ways:

  • "Crop" it with CSS by forcing a height of 100% and using overflow: hidden. This is not recommended, as it greatly reduces your control over what part(s) of the image gets cropped (faces, logos, etc.).
  • Include separate fields for different size images, and swap them out at various breakpoints using <picture> in your .tpl file. This provides the greatest control over exactly what the images look like, but doubles the burden on the person creating and uploading the images.
  • As a middle ground, consider using the Drupal modules Focal Point and Picture. Focal Point allows the user to upload a single image and use a simple interface to select the most important part of it. When we subsequently apply image styles to that image (such as different aspect ratios for different breakpoints using Picture), Drupal will ensure that the most important part of the image doesn't get cropped out.

Issue #2: Insufficient header spacing

Headers often provide another example of inflexible horizontal spacing. The image below shows a common design pattern - a logo on the far left with a menu floated to the right. Once again, it looks good at full width, but the logo and menu grow closer together as the viewport narrows, before it eventually collapses into a mobile layout. In this example (which only has four menu links), the links threaten to hit the logo as wide as 967px.

A header looking correct at full desktop width.
At 1200px, the header looks as designed.
At an intermediate width, the menu threatens to hit the logo.
At 968px, the menu is about to hit the logo. Keep in mind that most menus have more than four items, and that any link could change and make the navigation wider.
At 968px the menu needs to collapse into a hamburger so as not to hit the logo.
At 967px we need to collapse to a mobile layout, even though the viewport is still fairly wide.
On mobile, the collapsed menu looks natural.
At 400px, the collapsed menu looks natural.

You can view this example in browser or edit the source on Codepen.

What do I do about it?

As a designer, consider breaking your header into multiple rows. While many wish to conserve vertical real estate on the page by making the header as short as possible, remember that users are used to scrolling on the web.

As a front-end developer, your best bet is to include one or more intermediate breakpoints where the font size and/or size of the logo shrink to avoid having to collapse into a mobile menu at an unnaturally wide viewport.

Final Takeaways (TL;DR)

  • Test for all widths, not just common devices.
  • Your riskiest point for responsive layouts is 1 pixel ABOVE a given breakpoint.
  • Don't count on height. Content gets changed, even screens of the same width can be different heights, and people are used to scrolling on the web.