Table of Contents for
Mastering Responsive Web Design

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Mastering Responsive Web Design by Ricardo Zea Published by Packt Publishing, 2015
  1. Cover
  2. Table of Contents
  3. Mastering Responsive Web Design
  4. Mastering Responsive Web Design
  5. Credits
  6. About the Author
  7. Acknowledgment
  8. About the Reviewers
  9. www.PacktPub.com
  10. Preface
  11. What you need for this book
  12. Who this book is for
  13. Conventions
  14. Reader feedback
  15. Customer support
  16. 1. Harness the Power of Sass for Responsive Web Design
  17. The basic concepts of Sass for RWD
  18. Summary
  19. 2. Marking Our Content with HTML5
  20. The
  21. The
    element
  22. The
  23. The
    element
  24. The
  25. The
  26. Using WAI-ARIA landmark roles to increase accessibility
  27. A full HTML5 example page with ARIA roles and meta tags
  28. Output screenshots for desktop and mobile
  29. Summary
  30. 3. Mobile-first or Desktop-first?
  31. Sass mixins for the mobile-first and desktop-first media queries
  32. Dealing with legacy browsers
  33. How to deal with high-density screens
  34. Sometimes RWD is not necessarily the right solution
  35. Retrofitting an old website with RWD
  36. Retrofitting with AWD
  37. Retrofitting with RWD
  38. Summary
  39. 4. CSS Grids, CSS Frameworks, UI Kits, and Flexbox for RWD
  40. CSS grids
  41. CSS frameworks
  42. UI kits
  43. The pros and cons of CSS frameworks for RWD
  44. Creating a custom CSS grid
  45. Building a sample page with the custom CSS grid
  46. Stop using CSS grids, use Flexbox!
  47. Summary
  48. 5. Designing Small UIs Driven by Large Finger
  49. The posture patterns and the touch zones
  50. The nav icon – basic guidelines to consider for RWD
  51. The navigation patterns for RWD
  52. Summary
  53. 6. Working with Images and Videos in Responsive Web Design
  54. Third-party image resizing services
  55. The element and the srcset and sizes attributes
  56. Replacing 1x images with 2x images on the fly with Retina.js
  57. Making videos responsive
  58. The Vector Formats
  59. Summary
  60. 7. Meaningful Typography for Responsive Web Design
  61. Calculating relative font sizes
  62. Creating a Modular Scale for a harmonious typography
  63. Using the Modular Scale for typography
  64. Web fonts and how they affect RWD
  65. Sass mixin for implementing web fonts
  66. Using FlowType.js for increased legibility
  67. Summary
  68. 8. Responsive E-mails
  69. Don't overlook your analytics
  70. Recommendations for building better responsive e-mails
  71. Responsive e-mail build
  72. Third-party services
  73. Summary
  74. Index

Chapter 2. Marking Our Content with HTML5

Many consider that HTML is code. Well, it's not. HTML—any version of it—is a markup language.

A markup language is a computer language that can be read and understood by humans. It uses tags to define the parts of the content. HTML and XML are markup languages.

To further help the differentiation, a coding language involves much more complex abstractions, scripting, database connections, transmission of data in some shape or form via complex protocols, and so on. Coding is truly a magical world.

HTML can do all these, but it's way less complex and a lot easier to understand.

In this chapter, we're going to focus on the science behind marking up content. Content can come in many different forms: text, images, videos, forms, error messages, success messages, iconography, and so on. Also, the way a type of content behaves in the browser or the way the user interacts with it will tell us what type of HTML element that specific content should be marked as.

For example, many web designers make an anchor link <a href="#">Start 30 day trial</a> look like a button. Many web developers make the same anchor link behave like a button. Why not just use the <input type="button" value="Start 30 day trial"> element? Better yet, use the <button>Start 30 day trial</button> element that behaves exactly the same, is a lot easier to style, and allows the addition of HTML content if necessary.

The idea is to keep our markup as semantic as possible. Semantic markup basically means that we use HTML tags to describe what a specific piece of content is. Keeping a semantic markup has a lot of benefits:

  • It's very helpful for other web designers or developers who inherit our work, because they will spend less time reverse engineering what we have done and more time enhancing it.
  • It's also extremely helpful in terms of accessibility, because it allows assistive technologies to name the elements as they are: a button is actually a <button> and not a link <a href="#"> styled to look like a button.
  • SEO benefits greatly from semantic markup, because it allows search engines to index the content faster and more accurately.

Paying close attention to the content will go a long way for everyone in the chain—helping us during the project, helping the project itself, and eventually helping our users with and without assistive technology.

The best recommendation I can give you when marking up your content is listen to the content; it talks to you. It really does.

We will cover the following topics in this chapter:

  • HTML5 elements in action
  • Using Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA) landmark roles to increase accessibility
  • Important meta tags to consider for RWD
  • A full HTML5 example page with ARIA roles and meta tags

So, which HTML elements can we use now so we're sure our websites/apps look fine in all browsers? The answer is all elements.

On October 28, 2014, the W3C finalized the HTML5 standard. However, all major browsers had been supporting HTML5 elements for several years.

What this means for us is that even way before the W3C finalized the HTML5 standard, we could already use any HTML5 element. So if you've been building websites/apps with HTML5, keep doing it; if you haven't started to use HTML5 yet for any specific reason, this is the time to start.

The <main> element

As per the Mozilla Developer Network (MDN) definition:

The HTML Main Element (<main>) can be used as a container for the dominant contents of the document. The main content area consists of content that is directly related to, or expands upon the central topic of a section or the central functionality of an application. This content should be unique to the document, excluding any content that is repeated across a set of documents such as sidebars, navigation links, copyright information, site logos, and search forms (unless, of course, the document's main function is as a search form). Unlike <article> and <section>, this element does not contribute to the document outline.

Here are a few important points to remember about the <main> element:

  • The top-level content of a page should be included in the <main> element.
  • The content should be exclusive and unique to it.
  • The <main> element should never be included inside the <header>, <footer>, <nav>, <aside>, or <article> elements.
  • There can only be one <main> element per page.

Consider the following example:

<body>
    <main class="main-container" role="main">Content goes here
    </main>
</body>

Tip

For good measure, use HTML entities for special characters, for example, the ampersand character (&) is &amp; and the ellipsis character (…) is &hellip;.