Em

Next let’s discuss a different unit of measurement, one that we should generally be using when sizing text instead of pixels, and that is the “em”. The em is a better measurement for thinking about text. Unlike pixels, it is a relative unit of measurement. Applying a value of 1.1em to the font size of an element increases the size by 10 percent, whatever the starting font size is. This means that em-sized elements can depend on the sizes of other elements. This will give us some nice abilities that we will exploit below. I also bring this up at this point because it’s a unit that web designers generally prefer and, if we reinterpret our data above, actually makes for easier numbers. Let’s talk about that a bit more.

Historically the em comes from printing, where an em as a unit of measure is equal to the width of the capital letter M in any given typeface. When it comes to browsers, 1 em is equal to the default font size of the browser. So in our examples above, the default size of a p element is 1 em, an h2 element is 1.5 ems and an h1 element 2 ems. When expressed in ems, the pattern of the sizes is more obvious but that’s not surprising because typography geeks are more likely to talk in ems and not in pixels. Given the “coincidence” here, I presume that this was something the browser makers thought as well.

Because ems are generally the preferred unit for designers and because they express proportions better, we will use ems instead of pixels in all our discussions about sizing text.

Another interesting side effect of using ems is that nested elements with em measurement are compounded. Let me explain what I mean. Let’s say you have the following bit of HTML.

<p style="font-size: 1.2em;">This is a paragraph</p>

<div style="font-size: 1.2em;">
  <p style="font-size: 1.2em;">This paragraph is nested.</p>
</div>

Is the first paragraph the same font size as the second paragraph? No. The first paragraph is about 19 pixels in size, the second is about 23 pixels in size. The second is larger because it also picks up the font size increase of its parent div. The first paragraph is 20 percent larger than the default font size, the font size for the second increased by 20 percent because of the parent div and then increased 20 percent again by its own font setting.

As you may guess, this can lead to problems if you don’t pay close attention to how you nest and size your HTML. But it’s also a very valuable tool. If you want to change the text size of a given page and make everything just a bit bigger, you could change the styling for every HTML tag on the page or you could add a style rule to change the font size of the body tag to 1.1 ems and bump up the size all tags in one easy change by 10 percent. This is a very powerful tool and something we will come back to momentarily.

Rem

The nesting capability of ems can be either a blessing or a curse, depending on how you structure your HTML and CSS. Even though ems are great for sizing text, the negative side effect I mention led to the development of the rem, which stands for “root em”. If an element is sized with a rem instead of an em, the proportional size expressed in the em is sized in relation to the root of the document, the html tag. In other words, if we take our previous example and change the nested paragraph to use a rem, the size of the first paragraph and the second are now the same.

<p style="font-size: 1.2em;">This is a paragraph</p>

<div style="font-size: 1.2em;">
  <p style="font-size: 1.2rem;">This paragraph is nested.</p>
</div>

Using rems gives you the benefit of ems but makes it harder for you to accidentally change font sizes by nesting elements. Desktop browser support is good (IE 9+, Chrome, Firefox, Opera, Safari) but mobile browser support is ubiquitous in modern smartphones, so it can be safely used.

Line Height

Font size across mobile devices is remarkably consistent. Unfortunately line height (often called “leading”, referring to the strips of lead between lines of text in printing presses) has no such uniformity. Just for a few examples, IE 10 on Windows 8 defaults to around 18.4 pixels, Android-based browsers (including Kindle browsers), Firefox OS and Opera around 19.2 pixels, Windows Phone 7 around 21.44 pixels, and iOS around 20.8 pixels.

It would be very reasonable to wonder why these (seemingly) strange decimal numbers were chosen. But if we convert the pixel sizes to ems, some of them seem less arbitrary. Android browsers have a default line height of 1.2 ems and iOS browsers have a default line height of 1.3 ems. Internet Explorer seems to work a bit differently though, with line heights of 1.15 ems for version 10 (desktop) and 1.34 for version 7 and 8 on the phone. We are left with the sizes in Table 5-2.

Fortunately all of these browsers can be made consistent by a little CSS. Decide on the size you like, and set it with the CSS line-height property.

Responsive Text

Now that we have the core ideas in our mind, we can now think responsively and see how hard it is to style flexibly with text. Let’s take a simple example, exemplified by Figure 5-2. The HTML for it is straightforward.

<h1>Lorem ipsum dolor sit amet</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam vel justo eros...</p>

The CSS is as follows. The media query is missing from the first shot in Figure 5-2.

h1 {
  font-family: Helvetica, sans-serif;
  font-size: 2em;
}

p {
  font-family: Georgia, serif;
  font-size: 1.2em;
  line-height: 1.5em;
}

@media screen and (max-width: 400px) {
  body {
    font-size: 1.1em;
  }
}

Regardless of whether you would prefer the text to be smaller or larger on the phone, the technique is the same. Note that only the font size of the body was changed, but the heading and the paragraph both increased. The cascading effect of our em-based sizing makes it easy to change the size of all the text, larger or smaller, just by changing one element in a media query.

Plain Tables

First of all, there is a level of flexibility built into HTML tables. Unless explicit widths are set on columns, tables will flex without any special treatment, at least up to a point. In order to accommodate smaller screens, tables will insert line breaks between words in table cells causing the text to wrap (just as browsers insert line breaks when a line of text in a paragraph gets too long), stretching the table vertically. Once line breaks can no longer be added to make a table narrower, the table will stop shrinking. If that is larger than the size of your flexible layout, the table will break it. For example, let’s say you have a flexible layout that normally sizes just fine on an iPhone in portrait mode, which is 320 pixels wide. In this case the user can scroll vertically but not horizontally, because the width is 320 pixels and the browser knows that the user can’t scroll horizontally because the content is the size of the device viewport. Now you add a table that is too large that (we will assume in our hypothetical case) will render at a minimum width of 500 pixels. Now your flexible layout that was 320 pixels is actually 500 pixels in width, and the user will have to scroll both horizontally and vertically to see all of the content. This is obviously not ideal. We need a better way.

Scrolling Table

A very simple way to make your table scroll within the width of the window is to wrap it in a div and set overflow: auto on the div. Though the data on the right side of the table might initially be hidden, this technique allows the user to scroll the table horizontally to see the whole thing. The simplicity of this technique is its strongpoint. This works great unless you want to support Android 2.x, which doesn’t support scrolling an element in this way. You also have to be okay with the unsightly scrollbars that will appear on a desktop browser if the browser window is too small. Android 2.x is still quite popular at this time, so this technique really suffers. But perhaps in a few years this will no longer be the case.

De-table the Table

If the table is too large to fit on mobile devices, we can de-table the table by changing its layout. There are several techniques for doing this, although the result from all of them looks like Figure 5-3.

There are essentially two problems to solve here. First, the table elements have to have their default layout changed to something other than the default you get with HTML tables. Second, we want to get the column names from the header and put them to the left of the values as labels. Because I have three data rows and one row of header, this is going to be a difficult one to solve cleanly.

The first approach I tried is by Aaron Gustafson [http://blog.easy-designs.net/archives/2013/02/02/responsive-tables/]. To solve the first problem, he changes the tbody, tr, and td tags to display: block and hides the header. To solve the second problem, he repeats the header names in data attributes on the table cells and uses CSS to pull that out and display it when the media query kicks in. The table would look something like this:

<tbody>
  <tr>
    <td data-title="Page">Serving static files from Node.js</td>
    <td data-title="Feb 1">101</td>
    <td data-title="Feb 2">68</td>
    <td data-title="Feb 3">61</td>
    <td data-title="Feb 4">111</td>
    <td data-title="Feb 5">122</td>
    <td data-title="Feb 6">131</td>
    ...

The media query for de-tableing would look something like the following. I’ve highlighted the most important bits.

@media screen and (max-width: 960px) {
  thead {
    display: none;
  }

  tbody, tr, td {
    display: block;
  }

  td {
    padding-left: 50%;
  }

  td:first-child {
    background-color: #777;
    color: #FFF;
  }

  td:before {
    content: attr(data-title) ': ';
    display: inline-block;
    font-weight: bold;
    left: 10px;
    margin-right: 15px;
    position: absolute;
  }

  tr {
    margin-top: 15px;
  }
}

This is a very clever technique, though it has two flaws that we should mention. First, it doesn’t work in Windows Phone 7.5. Traffic for this device is quite low, so this won’t bother some people; however, it would be better to have a solution that worked for that device. Second, the extra data elements significantly expand the size of the table and repetition of content leads to maintenance annoyance though server or client-side templating can make this easier. This is a workable solution, but perhaps we can find an improvement.

A variation on this same display:block pattern can be found on CSS Tricks, a site run by Chris Coyier [http://css-tricks.com/examples/ResponsiveTables/responsive.php]. His approach put the labels for the data in the CSS. This is a selection from the CSS to implement this.

td:before {
  position: absolute;
  left: 0;
  padding-left: 10px;
}
     
td:nth-of-type(1):before { content: 'Page'; }
td:nth-of-type(2):before { content: 'Feb 1'; }
td:nth-of-type(3):before { content: 'Feb 2'; }
td:nth-of-type(4):before { content: 'Feb 3'; }
td:nth-of-type(5):before { content: 'Feb 4'; }
td:nth-of-type(6):before { content: 'Feb 5'; }
td:nth-of-type(7):before { content: 'Feb 6'; }
td:nth-of-type(8):before { content: 'Feb 7'; }
td:nth-of-type(9):before { content: 'Feb 8'; }
td:nth-of-type(10):before { content: 'Feb 9'; }
td:nth-of-type(11):before { content: 'Feb 10'; }
td:nth-of-type(12):before { content: 'Total'; }
td:nth-of-type(13):before { content: 'Max'; }
td:nth-of-type(14):before { content: 'Min'; }
td:nth-of-type(15):before { content: 'Avg'; }

One advantage that this approach has over the other is that it avoids messing up the DOM for this new display. It also cuts down on the duplication, so the label data is only duplicated once (the original data being in the header and the duplicated data in the CSS). However, now you have to keep your CSS in sync with your table data. Some may prefer this approach though I like it less. And it also doesn’t work on Windows Phone 7.5.

Before we spend more time on the labels, let’s solve the display issue with Internet Explorer. Moving everything to display: block did not work, so we will try something else. As it turns out, floating works great. As far as I can see, this works across all modern mobile browsers.

@media screen and (max-width: 960px) {

  td {
    float: left;
    padding: 8px 2% 8px 50%;
    position: relative;
    width: 48%;
  }
}

Space on the left is made for the labels, which we will come back to shortly. But as you can see, now that we learned how floats work (see Chapter 2 if you skipped it), this is a relatively straightforward approach.

Now back to the label problem. The issue here is that HTML and CSS don’t really solve this problem, at least not elegantly. This is a new technique that the browsers are not ready for, and when this happens often the best approach is to use JavaScript. Our goal is to have a plain HTML table that would work responsively that has no duplicate label information. Here is the full implementation, starting with the HTML.

<table>
  <thead>
    <tr>
      <td>Page</td>
      <td>Feb 1</td>
      <td>Feb 2</td>
      <td>Feb 3</td>
      <td>Feb 4</td>
      <td>Feb 5</td>
      <td>Feb 6</td>
      <td>Feb 7</td>
      <td>Feb 8</td>
      <td>Feb 9</td>
      <td>Feb 10</td>
      <td>Total</td>
      <td>Max</td>
      <td>Min</td>
      <td>Avg</td>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Serving static files from Node.js</td>
      <td>101</td>
      <td>68</td>
      <td>61</td>
      <td>111</td>
      ...

As you can see, the DOM is nice and clean. No extraneous attributes. Next comes the CSS.

td {
  border: solid 1px #CCC;
  padding: 3px 8px;
}

thead td {
  background-color: #777;
  outline: solid 1px #000;
  color: #FFF;
}

@media screen and (max-width: 960px) {
  td:first-child {
    background-color: #777;
    color: #FFF;
  }

  tr:nth-of-type(odd) {
    background-color: #eee;
  }

  thead {
    display: none;
  }

  td {
    float: left;
    padding: 8px 2% 8px 50%;
    position: relative;
    width: 48%;
  }

  td:before {
    content: attr(data-title) ': ';
    font-weight: bold;
    position: absolute;
    left: 0;
    padding-left: 10px;
  }
}

This CSS is a mixture of Gustafson’s and my own so that it will work in Windows Phone 7.5. The primary difference between my approach and those above that makes this work is that the previous approaches changed the CSS display attribute of the cells, which doesn’t work on Windows Phone 7.5. However, floats work nicely, so we use those to change the layout of the table. We solve the duplicate data problem with a script script (which uses a little jQuery, as you can see) that will dynamically add the data attributes when the page is loaded.

<script>
  $(document).ready(function () {

    var headerCells = $('thead td'),
    var dataCells = $('tbody td'),

    var i, labelIteration = 0, labelIterationMaxLength = headerCells.length;
    for (i = 0; i < dataCells.length; i++) {
      $(dataCells[i]).attr('data-title', headerCells[labelIteration].innerText);

      labelIteration++;
      if (labelIteration == labelIterationMaxLength)
        labelIteration = 0;
    }

  });
</script>

Assuming there aren’t any row or column spans, this seems to work pretty well. Of course there is a JavaScript dependency at this point, which some might not be comfortable with. This new approach gives you the same result on a small screen that we saw in Figure 5-3 above, though with the added bonus that it now works on Windows Phone 7.5.

FooTable

If you are okay with a JavaScript dependency, another choice to consider is using the FooTable library [http://themergency.com/footable/]. It also supports Windows Phone 7.5, which is a small bonus. This approach solves the problem by keeping the table format initially but collapsing the data, which you can drill down into. For example, here in Figure 5-4 is the same table we saw above using FooTable.

Frankly, there is no elegant way of solving this problem at this point. I have given you several options and there are more options/experiments out on the web for handling tables. As I said in the introduction, this is an area of web development that certainly needs to evolve and will over time.

HTML5 Video

Let’s start with the first case, that of using the HTML5 video element. I find that the HTML5 video is inconsistently flexible. I recorded a video and converted it to various video formats and the video was 568 pixels in width by default. To test this, I used the following.

<video controls src="/content/video/sample-video.webm">
  <source src="/content/video/sample-video.mp4" type="video/mp4" />
  <source src="/content/video/sample-video.ogg" type="video/ogg" />
</video>

<iframe style="width: 420px; height:315px;"
  src="//www.youtube.com/embed/Hq2KXudEjkI"
  frameborder="0"
  allowfullscreen>
</iframe>

<iframe src=http://player.vimeo.com/video/69553622
  style="width: 500px; height: 281px;"
  frameborder="0"
  webkitAllowFullScreen
  mozallowfullscreen
  allowFullScreen>
</iframe>

// Find all YouTube and Vimeo videos
var $allVideos = $("iframe[src^='http://www.youtube.com'],
  iframe[src^='http://player.vimeo.com']"),

  // The element that is fluid width
  $fluidEl = $("body");

// Figure out and save aspect ratio for each video
$allVideos.each(function () {

  $(this).data('aspectRatio', this.height / this.width)

    // and remove the hard coded width/height
    .removeAttr('height')
    .removeAttr('width'),
});

// When the window is resized
$(window).resize(function () {

  var newWidth = $fluidEl.width();

  // Resize all videos according to their own aspect ratio
  $allVideos.each(function () {

    var $el = $(this);
    $el
      .width(newWidth)
      .height(newWidth * $el.data('aspectRatio'));

  });

  // Kick off one resize to fix all videos on page load
}).resize();

Flexible Images

We will end this chapter with a discussion of flexible images, a problem that is solved easily unless you want it solved well. First let’s identify the problems and then start with the easy approaches since they will work fine in many cases.

<img src="my-dog.jpg" alt="my awesome dog." />

img {
  max-width: 100%;
}

.element-with-fancy-background {
  background-image: url(my-dog.jpg);
  -moz-background-size: 100%;
  -o-background-size: 100%;
  -webkit-background-size: 100%;
  background-size: 100%;
  background-repeat: no-repeat;
}

@media screen and (-webkit-min-device-pixel-ratio: 2) {
  //whatever CSS you need for higher resolution devices
}

@media (min-resolution: 159dpi) and (max-width: 160dpi) {
  //css
} 

@media (min-resolution: 1dppx) and (max-resolution: 2dppx) {
  //css
}

The first media query measures in terms of dots per inch, the second in terms of device pixel ratio. In terms of resolution, we can say that this device is not a high-resolution device. However, Firefox on the Galaxy SIII reports 320dpi and a 3dpr, so it is high-resolution. Note that this is a higher than what Chrome and the default browser report on the same device. Older versions of Opera on Android supported both of these versions of the resolution media query though the newer versions that are webkit-based only support the device pixel ratio media query above.

Windows Phone 7.5 and 8 only support the resolution media query for dpi but both are broken. They always display 96 dpi, though most (all?) newer Windows Phone 8 devices have higher-resolution screens.

All this means that we can know through media queries if the devices our users are using have high-resolution screens, unless they are using Windows Phone. But unless things change radically for Windows Phone, chances are that your users are not using those devices. You will just need to just make a choice and serve either low- or high-resolution images to these devices. As for the others, even though we may have to use two media queries to know the resolution, but we can know it.

So how do we use this information? Here’s an example of how we would use this for background images. Let’s say we have a div like this one.

<div class="my-dog-page">
</div>

The following CSS could be used to set the background image for that div appropriately.

.my-dog-page {
  background-image: url(dog-background-low-res.jpg);
  background-repeat: no-repeat;
  min-height: 264px;
  min-width: 200px;
}

@media (min-resolution: 2dppx) {
  .my-dog-page {
    background-image: url(dog-background.jpg);
  }
}

@media (-webkit-min-device-pixel-ratio: 2) {
  .my-dog-page {
    background-image: url(dog-background.jpg);
  }
}

Because background images are only downloaded when a CSS rule is applied, devices with low device/pixel ratios or don’t support these media queries will only download the low-resolution image. That is the good news. Unfortunately devices that do apply the media queries will download both the low-resolution and the high-resolution images because both rules applied.

Of course you might be wondering what to do for something that is supposed to be responsive and work across a variety of screen sizes. To do that you can just add in another media query, perhaps like this one.

@media (min-width: 450px) {
  .my-dog-page {
    background-image: url(dog-background-medium.jpg);
    min-height: 594px;
    min-width: 450px;
  }
}

You can also mix media queries and combine page width with resolution to get even finer-grained control over your sizes and resolutions and perhaps even solve the problem of downloading both low and high resolution images completely.

I have taken this approach to certain types of images and it has worked well. This kind of approach works best for images that are used in the design of a page. Perhaps you have images for the menu options or use image backgrounds for sections of the page. What this doesn’t work as well for is what I would call “content images.” These are usually image tags in a page, perhaps in an article or as a piece of messaging. Though you could use this approach for image tags in a page to hide/show the appropriate image tag, this would be a bad idea. If the browser sees multiple image tags it will download them all, even if it shows only one of them based on your media queries. This would be very detrimental for the performance of your page and is not very bandwidth friendly. This is where the proposed picture element and PictureFill can be of use.

<picture width="500" height="500">
  <source media="(min-width: 45em)" srcset="large-1.jpg 1x, large-2.jpg 2x">
  <source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
  <source srcset="small-1.jpg 1x, small-2.jpg 2x">
  <img src="small-1.jpg" alt="">
  <p>Accessible text</p>
</picture>

<script src="/scripts/picturefill.js"></script>

<span data-picture data-alt="Me as a horse">
  <span data-src="/content/picturefill/horseman-small-low-res.jpg"></span>
  <span data-src="/content/picturefill/horseman-small.jpg"
    data-media="(min-width: 320px) and (min-resolution: 2dppx)"></span>
  <span data-src="/content/picturefill/horseman-small.jpg"
    data-media="(min-width: 320px) and (-webkit-min-device-pixel-ratio: 2)"></span>
  <span data-src="/content/picturefill/horseman-medium.jpg"
    data-media="(min-width: 400px)"></span>
  <span data-src="/content/picturefill/horseman-full.jpg"
    data-media="(min-width: 800px)"></span>

  <noscript>
    <img src="/content/picturefill/horseman-small.jpg" alt="Me as a horse">
  </noscript>
</span>