Table of Contents for
The Modern Web

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition The Modern Web by Peter Gasston Published by No Starch Press, 2013
  1. The Modern Web
  2. Cover
  3. The Modern Web
  4. Advance Praise for
  5. Praise for Peter Gasston’s
  6. Dedication
  7. About the Author
  8. About the Technical Reviewer
  9. Acknowledgments
  10. Introduction
  11. The Device Landscape
  12. The Multi-screen World
  13. Context: What We Don’t Know
  14. What You’ll Learn
  15. A. Further Reading
  16. 1. The Web Platform
  17. A Quick Note About Terminology
  18. Who You Are and What You Need to Know
  19. Getting Our Terms Straight
  20. The Real HTML5
  21. CSS3 and Beyond
  22. Browser Support
  23. Test and Test and Test Some More
  24. Summary
  25. B. Further Reading
  26. 2. Structure and Semantics
  27. New Elements in HTML5
  28. WAI-ARIA
  29. The Importance of Semantic Markup
  30. Microformats
  31. RDFa
  32. Microdata
  33. Data Attributes
  34. Web Components: The Future of Markup?
  35. Summary
  36. C. Further Reading
  37. 3. Device-Responsive CSS
  38. Media Queries
  39. Media Queries in JavaScript
  40. Adaptive vs. Responsive Web Design
  41. Viewport-Relative Length Units
  42. Responsive Design and Replaced Objects
  43. Summary
  44. D. Further Reading
  45. 4. New Approaches to CSS Layouts
  46. Multi-columns
  47. Flexbox
  48. Grid Layout
  49. The Further Future
  50. Summary
  51. E. Further Reading
  52. 5. Modern JavaScript
  53. New in JavaScript
  54. JavaScript Libraries
  55. Polyfills and Shims
  56. Testing and Debugging
  57. Summary
  58. F. Further Reading
  59. 6. Device Apis
  60. Geolocation
  61. Orientation
  62. Fullscreen
  63. Vibration
  64. Battery Status
  65. Network Information
  66. Camera and Microphone
  67. Web Storage
  68. Drag and Drop
  69. Interacting with Files
  70. Mozilla’s Firefox OS and WebAPIs
  71. PhoneGap and Native Wrappers
  72. Summary
  73. G. Further Reading
  74. 7. Images and Graphics
  75. Comparing Vectors and Bitmaps
  76. Scalable Vector Graphics
  77. The canvas Element
  78. When to Choose SVG or Canvas
  79. Summary
  80. H. Further Reading
  81. 8. New Forms
  82. New Input Types
  83. New Attributes
  84. Datalists
  85. On-Screen Controls and Widgets
  86. Displaying Information to the User
  87. Client-side Form Validation
  88. The Constraint Validation API
  89. Forms and CSS
  90. Summary
  91. I. Further Reading
  92. 9. Multimedia
  93. The Media Elements
  94. Media Fragments
  95. The Media API
  96. Media Events
  97. Advanced Media Interaction
  98. Summary
  99. J. Further Reading
  100. 10. Web Apps
  101. Web Apps
  102. Hybrid Apps
  103. TV Apps
  104. Webinos
  105. Application Cache
  106. Summary
  107. K. Further Reading
  108. 11. The Future
  109. Web Components
  110. The Future of CSS
  111. Summary
  112. L. Further Reading
  113. M. Browser Support as of March 2013
  114. The Browsers in Question
  115. Enabling Experimental Features
  116. Chapter 1: The Web Platform
  117. Chapter 2: Structure and Semantics
  118. Chapter 3: Device-Responsive CSS
  119. Chapter 4: New Approaches to CSS Layouts
  120. Chapter 5: Modern JavaScript
  121. Chapter 6: Device APIs
  122. Chapter 7: Images and Graphics
  123. Chapter 8: New Forms
  124. Chapter 9: Multimedia
  125. Chapter 10: Web Apps
  126. Chapter 11: The Future
  127. N. Further Reading
  128. Introduction
  129. Chapter 1: The Web Platform
  130. Chapter 2: Structure and Semantics
  131. Chapter 3: Device-Responsive CSS
  132. Chapter 4: New Approaches to CSS Layouts
  133. Chapter 5: Modern JavaScript
  134. Chapter 6: Device APIs
  135. Chapter 7: Images and Graphics
  136. Chapter 8: New Forms
  137. Chapter 9: Multimedia
  138. Chapter 10: Web Apps
  139. Chapter 11: The Future
  140. Index
  141. About the Author
  142. Copyright

Responsive Design and Replaced Objects

One sticking point I haven’t yet addressed is when you have objects on a page—notably images, but also plug-ins like video and Flash. You can’t do much with the latter (especially as Flash won’t be supported on most of your users’ mobile devices anyway), but images present a unique set of obstacles to building responsively, which I’ll come to shortly.

Resizing most objects with percentages (or viewport-relative units if you go that way) is not a problem; you could quite simply set the max-width property to 100 percent to prevent the object ever being wider than its container:

img {
  height: auto;
  max-width: 100%;
}

Notice that I also set the auto value on the height property to maintain the object’s original aspect ratio—having a fixed height and a dynamic width (or vice versa) could distort the object displayed. Sometimes preserving the aspect ratio is going to mean empty spaces on your page on either the horizontal or vertical axis, as the object is too small for its container (you can see an example of this in Figure 3-5). If that’s the case, you can take advantage of the object-fit and object-position properties to better control how the object is displayed inside its parent.

(This image is “Evolution of Expression!” by kabils: . It is used under a Creative Commons license.)
Figure 3-5. An image that’s been resized to keep its aspect ratio, leaving empty space around it.

The first of those properties, object-fit, controls how the object in question is resized within its container. If you use the contain keyword value, the object is resized so the whole of it shows inside the container, with its aspect ratio preserved and with empty space being added on the horizontal or vertical axis as necessary. Alternatively, using the cover keyword makes the shortest length of the object equal to the shortest length of the container, with the longest length overflowing the container. Using the fill keyword would resize the object to match the container’s dimensions.

In the example file object-fit.html, you can see these three keywords compared. This example has three div elements with an img inside, each of which has a unique id value. To this markup, I apply the following code:

img {
  height: 100%;
  width: 100%;
}
#obj-fill { object-fit: fill; }
#obj-contain { object-fit: contain; }
#obj-cover { object-fit: cover; }

The results, which you can see in Figure 3-6, are as follows: The first element, #obj-fill, has been resized to the same dimensions as its parent, causing it to be squashed horizontally and stretched vertically, and that distortion obviously doesn’t look great; the element in the middle, #obj-contain, has kept its original aspect ratio but been resized so the entire img fits inside its parent, causing the “letterboxing” effect; finally, #obj-cover has also kept its aspect ratio but been resized so the whole of its parent is covered. To achieve this, the image has been scaled up and overflows the parent (I’ve hidden the overflow in this example).

Different values for the object-fit property (left to right): fill, contain, cover
Figure 3-6. Different values for the object-fit property (left to right): fill, contain, cover

By default, the object sits dead center of its parent when object-fit is applied, but you can change that with the object-position property. This property works like the background-position property in that you can use either two values to specify an offset from the top left of the container or extra positional keywords (top, right, bottom, left, center) to offset from another side. For example:

E { object-position: bottom 10px right 2em; }

The example file object-position.html shows three different values for the object-position property. The markup is essentially the same as in the previous example, but the relevant CSS for this has been updated:

img {
  height: 100%;
  width: 100%;
  object-fit: contain;
}
#obj-1 { object-position: center top; }
#obj-2 { object-position: center bottom; }
#obj-3 { object-position: right; }

The result is shown in Figure 3-7. All three img elements have the contain value applied to the object-fit property, but that’s just for the sake of illustration and not required. The first image, #obj-1, is positioned in the horizontal center of its parent and the vertical top; the next, #obj-2, is still at the horizontal center, but now the vertical bottom; the last image, #obj-3, has been cropped to portrait dimensions to better show it positioned to the right of its parent.

Different values for the object-position property
Figure 3-7. Different values for the object-position property

The Image Problem

Although you’ve seen that resizing and positioning objects using responsive techniques is quite straightforward, images are still a source of major problems in responsive design for a number of reasons. Chief among them is the question of file size; although not always the case, the chances are good that someone using a mobile device will be using 3G or 4G and will have reduced bandwidth compared to a desktop user. That being the case, you don’t want to have to serve them a large, heavy image that they have to download over their limited connection.

This is exacerbated by the increase in high-resolution screens. Standard-resolution (1DPR) bitmap images (like JPG and PNG) can look quite low quality on higher-resolution (2DPR) screens. HTML currently offers no way to provide higher-resolution images to devices, and even if it did, you still have the bandwidth problem. What’s the solution?

The HTML5 Responsive Images Solution

Unfortunately there is, as I write this, no native solution. Although a number of proposals have been put forward, none has been officially blessed yet. The proposal that seems to be the most popular is to use a new picture element, like so:

1 <picture alt="Description of image subject.">
2   <source srcset="small.jpg 1x, small-highres.jpg 2x">
3   <img src="small.jpg" alt="Description of image subject.">
  </picture>

Three key activities are at work here: 1 is the new picture element with the alt attribute describing the image (other standard attributes could also be used here); 2 is the source element, which lists different source alternatives using the srcset attribute—what you see here are two alternative image sources, one for standard screens and one for higher-resolution screens, using the number of the screens DPR, which you saw earlier in this chapter; finally, 3 is the current img element, which you use as fallback for older browsers that haven’t implemented picture yet.

Warning

Remember this suggestion is only the most prominent as I write this; it may not be the final syntax.

So this syntax allows for testing device resolution, but what about other media queries? You can add those with further source elements:

<picture alt="Description of image subject.">
  <source srcset="small.jpg 1x, small-hi-res.jpg 2x">
  <source media="(min-width: 481px)" srcset="med.jpg 1x, med-hi-res.jpg 2x">
  <img src="small.jpg" alt="Description of image subject.">
</picture>

In this example, you can see an extra source element using the media attribute to set up a media query and serving a different set of images if that query is true. I have to say that although this syntax works, I don’t like it much; it’s repetitious for a start and, if used on a page with multiple images, leads to maintainability issues. That said, no other simpler suggestion has been proposed.

The WHATWG’s current proposal is to also use the srcset attribute, but only on the img element. This option allows images to be served dependent on screen resolution, but not with any other media query. I want to make this really clear: This is not “official,” only a proposal.

Plenty of third-party solutions have been created, notable among them Matt Wilcox’s Adaptive Images, which uses PHP and Apache to resize images on the server and serve them to users depending on their device’s attributes. But while this option works well, it does depend on a specific server configuration that isn’t available to everyone and also adds a reliance on JavaScript. This problem still waits to be solved natively.