Table of Contents for
Responsive Web Design with HTML5 and CSS3 - Second Edition

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Responsive Web Design with HTML5 and CSS3 - Second Edition by Ben Frain Published by Packt Publishing, 2015
  1. Cover
  2. Table of Contents
  3. Responsive Web Design with HTML5 and CSS3 Second Edition
  4. Responsive Web Design with HTML5 and CSS3 Second Edition
  5. Credits
  6. About the Author
  7. About the Reviewers
  8. www.PacktPub.com
  9. Preface
  10. What you need for this book
  11. Who this book is for
  12. Conventions
  13. Reader feedback
  14. Customer support
  15. 1. The Essentials of Responsive Web Design
  16. Defining responsive web design
  17. Setting browser support levels
  18. Our first responsive example
  19. The shortcomings of our example
  20. Summary
  21. 2. Media Queries – Supporting Differing Viewports
  22. Media query syntax
  23. Combining media queries
  24. Using media queries to alter a design
  25. Considerations for organizing and authoring media queries
  26. Combine media queries or write them where it suits?
  27. The viewport meta tag
  28. Media Queries Level 4
  29. Summary
  30. 3. Fluid Layouts and Responsive Images
  31. Introducing Flexbox
  32. Getting Flexy
  33. Responsive images
  34. Summary
  35. 4. HTML5 for Responsive Web Designs
  36. Starting an HTML5 page the right way
  37. Easy-going HTML5
  38. New semantic elements in HTML5
  39. HTML5 text-level semantics
  40. Obsolete HTML features
  41. Putting HTML5 elements to use
  42. WCAG and WAI-ARIA for more accessible web applications
  43. Embedding media in HTML5
  44. Responsive HTML5 video and iFrames
  45. A note about 'offline first'
  46. Summary
  47. 5. CSS3 – Selectors, Typography, Color Modes, and New Features
  48. Anatomy of a CSS rule
  49. Quick and useful CSS tricks
  50. Word wrapping
  51. Facilitating feature forks in CSS
  52. New CSS3 selectors and how to use them
  53. CSS3 structural pseudo-classes
  54. CSS custom properties and variables
  55. CSS calc
  56. CSS Level 4 selectors
  57. Web typography
  58. New CSS3 color formats and alpha transparency
  59. Summary
  60. 6. Stunning Aesthetics with CSS3
  61. Box shadows
  62. Background gradients
  63. Repeating gradients
  64. Background gradient patterns
  65. Multiple background images
  66. High-resolution background images
  67. CSS filters
  68. A warning on CSS performance
  69. Summary
  70. 7. Using SVGs for Resolution Independence
  71. The graphic that is a document
  72. Creating SVGs with popular image editing packages and services
  73. Inserting SVGs into your web pages
  74. Inserting an SVG inline
  75. What you can do with each SVG insertion method (inline, object, background-image, and img)
  76. Extra SVG capabilities and oddities
  77. Animating SVG with JavaScript
  78. Optimising SVGs
  79. Using SVGs as filters
  80. A note on media queries inside SVGs
  81. Summary
  82. 8. Transitions, Transformations, and Animations
  83. CSS3 2D transforms
  84. CSS3 3D transformations
  85. Animating with CSS3
  86. Summary
  87. 9. Conquer Forms with HTML5 and CSS3
  88. Understanding the component parts of HTML5 forms
  89. HTML5 input types
  90. How to polyfill non-supporting browsers
  91. Styling HTML5 forms with CSS3
  92. Summary
  93. 10. Approaching a Responsive Web Design
  94. View and use the design on real devices
  95. Embracing progressive enhancement
  96. Defining a browser support matrix
  97. Tiering the user experience
  98. Linking CSS breakpoints to JavaScript
  99. Avoid CSS frameworks in production
  100. Coding pragmatic solutions
  101. Use the simplest code possible
  102. Hiding, showing, and loading content across viewports
  103. Validators and linting tools
  104. Performance
  105. The next big things
  106. Summary
  107. Index

Coding pragmatic solutions

When it comes to front-end web development, 'ivory towered idealism' is a particular bugbear of mine. While we should always endeavor try to do things 'the right way', pragmatism must always win out. Let me give you an example (the finished code is example_10-02). Suppose we have a button to style that opens an off-canvas menu. Our natural inclination might be to mark it up something like this:

<button class="menu-toggle js-activate-off-canvas-menu">
    <span aria-label="site navigation">&#9776;</span> menu
</button>

Nice and simple. It's a button so we have used the button element. We have used two different HTML classes on the button, one will be a hook for CSS styling (menu-toggle), and the other as a JavaScript hook (js-activate-off-canvas-menu). In addition, we are using the aria-label attribute (ARIA is covered in more detail in Chapter 4, HTML5 for Responsive Web Designs) to communicate to screen readers the meaning of the character inside the span. In this example, we have used the HTML entity &#9776; which is the Unicode character 'Trigram for Heaven'. It's used here merely because it looks like the 'Hamburger icon' often used to symbolize a menu.

Tip

If you'd like some solid advice on when and how to use the aria-label attribute I thoroughly recommend the following post on the Opera developer site by Heydon Pickering: https://dev.opera.com/articles/ux-accessibility-aria-label/

At this point, we seem to be in good shape. Semantic, highly accessible markup and classes to separate concerns. Great. Let's add some styling:

.menu-toggle {
    appearance: none;
    display: inline-flex;
    padding: 0 10px;
    font-size: 17px;
    align-items: center;
    justify-content: center;
    border-radius: 8px;
    border: 1px solid #ebebeb;
    min-height: 44px;
    text-decoration: none;
    color: #777;
}

[aria-label="site navigation"] {
    margin-right: 1ch;
    font-size: 24px;
}

Open this up in Firefox and this is what we see:

Coding pragmatic solutions

Not exactly what we were hoping for. In this case, the browser has decided we've gone too far; Firefox simply won't allow us to use a button element as a Flex container. This is a very real conflict for a developer. Do we choose the right element or the right aesthetic? Given that ideally, we would like to have the menu 'hamburger icon' on the left and the word 'menu' on the right.

Tip

You can see in the prior code we have used the appearance property. It's used to remove the browsers default styling for form elements, and has had a potted history. It was specified by the W3C for some time and then later dropped, leaving behind vendor-prefixed versions of the property in both Mozilla and WebKit browsers. Thankfully, it's now back on the standards track: http://dev.w3.org/csswg/css-ui-4/#appearance-switching

When a link becomes a button

I won't lie. Given this conundrum, I usually opt for the latter. Then I try and make up for the fact I'll be using the wrong element by choosing the next best element and changing the ARIA role where possible. In this case, while our menu button is certainly not a link (after all, it doesn't take the user anywhere), it's an a tag that I will be using. I've decided it's the next best thing—more like a button than any other element. And by using a link we can achieve the desired aesthetic. Here's the markup I'd go with. Note the added ARIA role on the a tag to indicate its role as a button (and not a link which is the default) to assistive technology:

<a class="menu-toggle js-activate-off-canvas-menu" role="button">
    <span aria-label="site navigation">&#9776;</span> menu
</a>

It's not perfect but it's a pragmatic solution. Here's the two (button element on the left, a tag on the right) next to each other in Firefox (version 39.0a2 if you're curious):

When a link becomes a button

Of course, for this simplistic example, we could change the display from flex to block and play around with the padding until our desired aesthetic was achieved. Or, we could keep the button element and nest another semantically meaningless element (span) and make that a Flex container. There are trade-offs whichever approach you favor.

Ultimately, it's up to us to markup documents as sensibly as possible. At one end of the scale, there are developers that only markup with divs and spans to ensure no unwanted styles from the browser. The cost being no inherent meaning from their elements and in turn, no 'free' accessibility. At the other end of the scale are markup purists, who will only ever markup content in what they consider to be the correct element, regardless of how 'off' the visuals might end up as a result. There is a middle ground. I feel that's the sensible and most productive place to be.