Wk 3/Tut 2 : Responsive Web Design – Part 1

Responsive Web Design is a term initially coined by web designer/developer Ethan Marcotte. It is now a W3C Candidate Recommendation, ready to be implemented by all modern browser vendors. Following on from support in CSS2 for different media types such as screen and print, it essentially a set of additional media types based mostly on width (or not as widely used height). It could also be considered a subset of a more far-reaching movement called Progressive enhancement – in which all content is designed to gracefully degrade to the lowest common denominator.

Progression of Responsive Approaches

Luke Wroblewski, author of Mobile First, writes and speaks extensively on the subject. In this article he gives an excellent run down of the progression of responsiveness in approaches.

Mostly Fluid

  • larger margins on big screens
  • fluid grids
  • images that scale
  • mainly changes layout in narrowest incarnation by stacking columns (less essential information below)

Column Drop

  • using the same stacking column idea as Mostly Fluid but the width of each column stays mostly consistent.

Layout Shifter

  • Goes further to deliberately craft unique layouts for different screen sizes.

Tiny Tweaks

  • Not really relevant to most websites as it assumes you have a single column layout with few elements and can simply make tweaks to font sizes (larger in smallest screen for easy reading) and image layout (one per line centred in smallest screen for instance).

Off Canvas

  • Move secondary or occasional use information off-screen to slide back in with various triggers.

Choosing Break Points (targeting ranges of or addressing specific Viewports)

Rather than target specific devices, a current list of which would change monthly these days, the general idea is that you consider typical screen widths and at which points to alter your content.

As you set up your Media Queries you must take your actual content into consideration and subjectively apply that to a loose current understanding of where the majority of devices fall in perceived screen dimensions. For instance the iPad with Retina display reches 2048×1536 pixels or 264ppi, however that is an exact doubling of 1024×768 at which content designed for those dimensions will appear completely normal as the iPad intuitively zooms in 200%.

For instance, at the most basic level one could set up a break point right above the size of most smartphones:

@media (min-width: 500px){/*selectors*/{/*properties*}}
@media (max-width: 499px){/*selectors*/{/*properties*}}

For more advanced possibilities check out these articles:

What do you do with the Navigation Menu?

Brad Frost has a great collection of common implementations.

What do you do with Tables?

Responsive Data Table Roundup

Other RWD Resources




Flexible Fonts:

It’s best practice these days to use a fixed Base font size and relative proportions to this for every other declared size. This can be done through either:

  • % – using decimal percentages is not the best choice.
  • Ems – the most compatible and what brings support to IE in general when a viewer may change the font size in their browser and expect all the fonts to change proportionally. You can get caught in calculation problems though when you have multiple nested styles.
  • REMs – most accurate as they always refer back to the Base Font size regardless of their positioning in nested styles. Some compatibility issues with older browsers.

Here are 2 examples of free online tools to help with your calculations:

Responsive Testing:

Responsive Design Exercise – Part 1

Either continue with your developed example from Tutorial 1 Exercise, begin a fresh page (populated by some content from your final project if you have any!), or follow along with Dave Wallace’s example.

Apply the Mostly Fluid approach:

  • fluid column grids
  • make all images flexible with min & max widths.
  • make all fonts adaptive by basing them on EMs or REMs.
  • Create at least 1 Media Query and:
    • Stack at least 1 column below the main content.
    • Make at least one other content change within this query.