Mastering Responsive Web Design with HTML5 and CSS3 (2015)

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 & and the ellipsis character (…) is ….

The <article> element

As per the MDN definition:

The HTML Article Element (<article>) represents a self-contained composition in a document, page, application, or site, which is intended to be independently distributable or reusable, e.g., in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, or any other independent item of content. Each <article> should be identified, typically by including a heading (h1-h6 element) as a child of the <article> element.

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

· Any self-contained content should be placed inside the <article> element.

Self-contained means that if we take the <article> element and everything inside it out into another context, all the content is self-explanatory and does not need anything else around it to be understood.

· An <article> can be nested inside another <article> element.

· There can be more than one <article> element in a single page.

Consider the following example:

<body>

<article class="article-container flex-container">

Content goes here

</article>

</main>

</body>

The <section> element

As per the MDN definition:

The HTML Section Element (<section>) represents a generic section of a document, i.e., a thematic grouping of content, typically with a heading. Each <section> should be identified, typically by including a heading (<h1>-<h6> element) as a child of the <section>element.

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

· The <section> element can be used to encapsulate a group of related content. This related content doesn't necessarily have to make sense if we take it out of the page's context.

· A safe and valid way to use the <section> element is to place it inside an <article> element. You can certainly use the <article> element without a <section> element. It's recommended, although not required, to include a heading element (<h1>, <h2>, <h3>, and so on) when using the <section> element.

· It can be confusing to know when to use the <section> element and when to use the <article> element. If you're in doubt, you can choose either element.

· There can be more than one <section> in a single page.

Consider the following example:

<body>

<section class="main-content">

<header>

<h1>The <code><main></code> element </h1>

</header>

<p>As per the MDN definition:</p> <blockquote>

<p>The HTML Main Element (<code><main></code>) represents…</p>

</blockquote>

</section>

</article>

</main>

</body>

The <aside> element

As per the MDN definition:

The HTML <aside> element represents a section of the page with content connected tangentially to the rest, which could be considered separate from that content. These sections are often represented as sidebars or inserts. They often contain the definitions on the sidebars, such as definitions from the glossary; there may also be other types of information, such as related advertisements; the biography of the author; web applications; profile information or related links on the blog.

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

· Content that is tangential to the main content can be included in an <aside> element. If this content was to be separated from the main content, it would still make sense on its own.

· There can be more than one <aside> in a single page.

Consider the following example:

<body>

<h1>The <code><main></code> element </h1>

</header>

<p>As per the MDN definition:</p>

<p>The HTML Main Element (<code><main></code>)

represents…</p>

</blockquote>

</section>

<aside class="side-content" role="complementary">

<h2>What Does "Semantic HTML" Mean?</h2>

<p>Semantic markup basically means that we use HTML tags

to describe what a specific piece of content is.</p>

</aside>

</article>

</main>

</body>

Tip

Tangential content means that the content refers to the subject at hand, but it's not part of the main message. If this content inside the <aside> element is removed, the main message is not affected.

The <header> element

Usually, we think that the top section of our site/app is the header, and this is correct. The editorial name for that top section is the masthead.

However, from an HTML5 standpoint, there's a difference between a masthead and a header.

The masthead is the main header of our site/app and there can be only one. It usually contains the logo, some navigation, maybe a search field, and so on. The header can be considered the top area of any section and there can be more than one header.

Notice that we're not talking about the <header> element, at least not yet.

The masthead can be built using the <header> element, but the <header> element can also be used in other parts of the same page.

Here's the definition from MDN:

The HTML <header> Element represents a group of introductory or navigational aids. It may contain some heading elements but also other elements like a logo, wrapped section's header, a search form, and so on.

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

· A good rule of thumb is to use a <header> element inside a <section> element.

· We can wrap a heading (h1 to h6) inside a <header> element if we think it is necessary, but this is not really a common practice or required.

· There can be more than one <header> element in a single page.

In the following example, there are two highlighted <header> sections, the masthead and a header inside a <section> element:

<body>

<header class="masthead" role="banner">

<div class="logo">Mastering RWD with HTML5 & CSS3</div>

<div class="search" role="search">

<form>

<label>Search:

<input type="text" class="field">

<button>Search Now!</button>

</label>

</form>

</div>

</header>

<header>

<h1>The <code><main></code> element</h1>

</header>

<p>As per the MDN definition:</p>

<p>The HTML Main Element (<code><main></code>) represents…</p>

</blockquote>

</section>

<h2>What Does "Semantic HTML" Mean?</h2>

<p>Semantic markup basically means that we use HTML tags to describe what a specific piece of content is.</p>

</aside>

</article>

</main>

</body>

The <footer> element

As per the MDN definition:

The HTML Footer Element (<footer>) represents a footer for its nearest sectioning content or sectioning root element. A footer typically contains information about the author of the section, copyright data or links to related documents.

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

· It should always contain any information about its containing parent element.

· Although the term footer implies the bottom section of a page, article, or app, the <footer> element doesn't necessarily have to be at the bottom.

· There can be more than one <footer> element in a single page.

Consider the following example:

<body>

<div class="logo">Mastering RWD with HTML5 & CSS3</div>

<form>

<label>Search:

<button>Search Now!</button>

</label>

</form>

</div>

</header>

<h1>The <code><main></code> element</h1>

</header>

<p>As per the MDN definition:</p>

<p>The HTML Main Element (<code><main></code>) represents…</p>

</blockquote>

</section>

<h2>What Does "Semantic HTML" Mean?</h2>

<p>Semantic markup basically means that we use HTML tags to describe what a specific piece of content is.</p>

</aside>

</article>

<footer class="main-footer" role="contentinfo">

<ul class="nav-container" role="navigation">

<li><a href="#">Footer Link 1</a></li>

<li><a href="#">Footer Link 2</a></li>

<li><a href="#">Footer Link 3</a></li>

<li><a href="#">Footer Link 4</a></li>

<li><a href="#">Footer Link 5</a></li>

</ul>

</footer>

</main>

</body>

The <nav> element

As per the MDN definition:

The HTML Navigation Element (<nav>) represents a section of a page that links to other pages or to parts within the page: a section with navigation links.

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

· It is used to group a list or collection of links. The links can either point to external resources or to other pages within the site/app.

· It's common practice to use an unordered list <ul> inside the <nav> element to structure the links, because it's easier to style.

· Including a <nav> in the <header> element is also a common practice but not required.

· Not all groups of links have to be inside a <nav> element. If we have a list of links inside a <footer> tag, then its isn't really necessary to include those links in a <nav> as well.

· There can be more than one <nav> element in a single page, for example, a main navigation, a utility navigation, and a <footer> navigation.

Consider the following example:

<body>

<div class="logo">Mastering RWD with HTML5 & CSS3</div>

<form>

<label>Search:

<button>Search Now!</button>

</label>

</form>

</div>

</header>

<nav class="main-nav" role="navigation">

<ul class="nav-container">

<li><a href="#">Link 1</a></li>

<li><a href="#">Link 2</a></li>

<li><a href="#">Link 3</a></li>

<li><a href="#">Link 4</a></li>

</ul>

</nav>

<h1>The <code><main></code> element</h1>

</header>

<p>As per the MDN definition:</p>

<p>The HTML Main Element (<code><main></code>) represents…</p>

</blockquote>

</section>

<h2>What Does "Semantic HTML" Mean?</h2>

<p>Semantic markup basically means that we use HTML tags to describe what a specific piece of content is.</p>

</aside>

</article>

<li><a href="#">Footer Link 1</a></li>

<li><a href="#">Footer Link 2</a></li>

<li><a href="#">Footer Link 3</a></li>

<li><a href="#">Footer Link 4</a></li>

<li><a href="#">Footer Link 5</a></li>

</ul>

</footer>

</main>

</body>

Using WAI-ARIA landmark roles to increase accessibility

One of the most neglected aspects of the web is accessibility, unless you are part of a group dedicated to this subject. As web designers and web developers, we rarely think about handicapped users accessing the web and using our websites or apps with screen readers and other assistive technologies. We actually think first about supporting legacy browsers rather than increasing the accessibility of our products.

In this chapter, we're going to touch on what WAI-ARIA landmark roles are and how they can be easily implemented in our markup, enhancing the semantics of our documents to provide those users with assistive technology a better and pleasant experience when they navigate our websites/apps with their keyboards on any modern browser.

Note

WAI-ARIA stands for Web Accessibility Initiative – Accessible Rich Internet Applications.

WAI-ARIA landmark roles

WAI-ARIA landmark roles can also be referred to as ARIA roles, so that's the term we're going to use.

An ARIA role looks like this when implemented in an HTML5 element:

There are really multiple ARIA roles at our disposal, but in this book we're going to focus on the ones that are easier to implement and that will enhance the accessibility of our websites/apps efficiently.

The banner role

Here are a few important points to remember:

· This role is usually applied to the top <header> of the page.

· The header region contains the most prominent heading or title of a page.

· Usually, the content that has role="banner" appears constantly across the site rather than in a single specific page.

· Only one role="banner" is allowed per page/document.

Consider the following example:

<header class="masthead" role="banner">

<div class="logo">Mastering RWD with HTML5 & CSS3</div>

<form>

<label>Search:

<button>Search Now!</button>

</label>

</form>

</div>

</header>

The navigation role

Here are a few important points to remember:

· This role is usually applied to the <nav> element, but it can also be applied to other containers such as <div> or <ul>.

· It describes a group of navigational elements/links. These links can be either to navigate the site or the page they appear on.

· There can be more than one role="navigation" per page.

Consider the following example where the role is applied to the main <nav> element:

<nav class="main-nav" role="navigation">

</ul>

</nav>

Consider the following example where the role is applied to the <ul> element of the footer navigation:

<ul class="nav-container" role="navigation">

<li><a href="#">Footer Link 1</a></li>

<li><a href="#">Footer Link 2</a></li>

<li><a href="#">Footer Link 3</a></li>

<li><a href="#">Footer Link 4</a></li>

<li><a href="#">Footer Link 5</a></li>

</ul>

</footer>

There is no particular preference as to which element we add the navigation role to. It's the same if we add it to the <nav> element or the <ul> element.

The main role

Here are a few important points to remember:

· This role is usually applied to the <main> element of the page.

· The container of the main/central subject of the page should be marked with this role.

· Only one role="main" is allowed per page/document.

Consider the following example:

<body>

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

</main>

</body>

The contentinfo role

Here are a few important points to remember:

· This role is usually applied to the main <footer> element of the page.

· This is the section that contains information about the document/site/app.

· If the section contains, for example, a copyright link, footnotes, links to privacy statement, or terms and conditions, it's a good candidate for role="contentinfo".

· Only one role="contentinfo" is allowed per page/document.

Consider the following example:

<footer class="main-footer" role="contentinfo">

<li><a href="#">Footer Link 1</a></li>

<li><a href="#">Footer Link 2</a></li>

<li><a href="#">Footer Link 3</a></li>

<li><a href="#">Footer Link 4</a></li>

<li><a href="#">Footer Link 5</a></li>

</ul>

</footer>

The search role

Here are a few important points to remember:

· This role is usually applied to the <form> element that belongs to the search feature of the page/app.

· If the search form is wrapped inside a <div> element, this role can also be applied to that <div> element. If this is the case, then there's no need to add it to the child <form> element.

· There can be more than one role="search" per page as long as the control is an actual search feature. For example, using the role="search" on a contact form is incorrect and unsemantic.

Consider the following example where the role is applied to the site's search <form> element:

<form role="search">

<label>Search:

<button>Search Now!</button>

</label>

</form>

</div>

The form role

Here are a few important points to remember:

· This role is usually applied to a <div> element that contains some type of form, except the main search form of the site/app, for example, contact forms, registration forms, payment forms, and so on.

· It should not be applied to the actual <form> element, because this element already has default role semantics that assist technology support.

Consider the following example:

<div class="contact-form" role="form">

<h2>Have Questions About HTML5?</h2>

</header>

<form>

<label class="label-col">Email: <input type="email" class="field email" id="email" required></label>

</div>

<label for="comments">Comments:</label>

<button>Send Question!</button>

</form>

</div>

The complementary role

Here are a few important points to remember:

· This role is usually applied to an <aside> element.

· It should be used on a region that contains supporting content; if separated from the content, it can still make sense on its own. This is pretty much the description of the <aside> element.

· There can be more than one role="complementary" per page.

Consider the following example:

<aside class="side-content" role="complementary">

<h2>What Does "Semantic HTML" Mean?</h2>

<p>Semantic markup basically means that we use HTML tags to describe what a specific piece of content is.</p>

</aside>

Note

WAI-ARIA roles explained

If you're curious about the list of ARIA roles, you can visit the Web Platform website where the explanations are simple and very easy to understand: https://specs.webplatform.org/html-aria/webspecs/master/#docconformance

Important meta tags to consider for RWD

There are many ways web designers and developers use meta tags, but those extensive explanations are outside the scope of this book, so we're going to focus on the bits and pieces that are relevant and work as intended for RWD. 

The following meta tags are very important for our responsive site/app. These meta tags are not just for HTML5 pages, they will work with any version of HTML.

Let's get started.

The viewport meta tag

The viewport meta tag is the most important meta tag for RWD. It was introduced by Apple in their mobile Safari browser. Now, other mobile browsers support it as well. Oddly enough, this meta tag is not part of any web standards of any kind, yet it is mandatory if we want our responsive sites/apps to display correctly on small screens.

The recommended syntax of this meta tag is as follows:

Here are a few important points to remember:

· The name="viewport" directive describes the type of meta tag.

· The content="width=device-width, initial-scale=1" directive does several things:

· The width property defines the size of the viewport meta tag. We can also use specific pixel widths, for example, width=960.

· The device-width value is the width of the screen at 100 percent zoom in CSS pixels.

· The initial-scale value defines the zoom level the page should be shown at when it's first loaded. 1 equals 100 percent zoom and 1.5 equals 150 percent zoom.

· With this syntax, users will be able to zoom in if they want to. This is a UX best practice.

Note

This book strongly discourages the use of the following viewport properties: maximum-scale=1 and user-scalable=no. By using these viewport properties, we deny the users the ability to zoom in our website/app. We never know when zooming may be important for anyone, so it's best to steer away from including those viewport properties.

To help websites that are not responsive (yet) display a bit better on small screens, add the specific pixel width the site was built at. For example, if a website is as wide as 960px, add this viewport meta tag to it:

If you're interested in reading in more detail about the viewport meta tag, MDN explains it very well: https://developer.mozilla.org/en/docs/Mozilla/Mobile/Viewport_meta_tag.

The X-UA-Compatible meta tag

The X-UA-Compatible meta tag targets only Internet Explorer and its Compatibility View feature. As we all know, Microsoft introduced Compatibility View in IE8.

The recommended syntax of this meta tag looks like this:

Here are a few important points to remember:

· The http-equiv="X-UA-Compatible" directive tells IE that a certain rendering engine needs to be used to render a page.

· The content="IE=edge" directive tells IE that it should use its latest rendering HTML and JavaScript engines.

· Using this meta tag to trigger IE's latest HTML and JavaScript engines is very good, because the latest version of IE always has the latest security updates and support for many more features.

Tip

There's no need to use the chrome=1 value anymore, since Chrome Frame was retired in February 2014.

Note

Google Chrome Frame was a plugin for old versions of IE. When installed, it would replace certain modules within IE, such as rendering and JavaScript engines, thus improving the user experience. In other words, it was like installing a small version of Google Chrome on top of IE.

The charset meta tag

The charset meta tag tells the browser which character set to use to interpret the content. Some say it isn't that important to include because the server itself sends the character set to the browsers via HTTP headers anyway. But it's always a good measure to include it in our pages as well.

If charset is not declared in the HTML and the server doesn't send the character set to the browser, it's likely that some special characters may display incorrectly.

The recommended syntax of this meta tag in HTML5 is like this:

Here are a few important points to remember:

· This meta tag was created exclusively for HTML5 documents. The main benefit is that there's less code to write.

· For HTML 4 and XHTML, you should use the following syntax:

· Another common value is ISO-8859-1, but UTF-8 is more widely used because there is a better chance of the browser interpreting the content correctly.

Note

UTF-8 stands for Unicode Transformation Format-8.

A full HTML5 example page with ARIA roles and meta tags

Now that we have gone through a few essential HTML5 elements, the ARIA roles they can be applied to, and the proper meta tags for display, let's visualize all of them in a full HTML5 page:

<!DOCTYPE html>

<html>

<head>

<meta charset="utf-8">

<meta http-equiv="X-UA-Compatible" content="IE=edge">

<meta name="viewport" content="width=device-width, initial-scale=1">

<title>Mastering RWD with HTML5 & CSS3</title>

</head>

<body>

<div class="logo">Mastering RWD with HTML5 & CSS3</div>

<form>

<label>Search:

<button>Search Now!</button>

</label>

</form>

</div>

</header>

</ul>

</nav>

<h1>Chapter 2: Marking Our Content with HTML5</h1>

<p>Many consider that HTML is "code". Well, it's not. HTML, any version of it, is a "markup" language. </p>

<h1>The <code><main></code> element </h1>

</header>

<p>As per the MDN definition:</p>

<p>The HTML Main Element (<code><main></code>) represents…</p>

</blockquote>

</section>

<h2>What Does "Semantic HTML" Mean?</h2>

<p>Semantic markup basically means that we use HTML tags to describe what a specific piece of content is.</p>

</aside>

</article>

<h2>Have Questions About HTML5?</h2>

</header>

<form>

<label class="label-col">Email: <input type="email" class="field email" id="email" required></label>

</div>

<label for="comments">Comments:</label>

<button>Send Question!</button>

</form>

</div>

<li><a href="#">Footer Link 1</a></li>

<li><a href="#">Footer Link 2</a></li>

<li><a href="#">Footer Link 3</a></li>

<li><a href="#">Footer Link 4</a></li>

<li><a href="#">Footer Link 5</a></li>

</ul>

</footer>

</main>

</body>

</html>

As a bonus, let's take a look at the SCSS that ties all this together into a nice responsive page.

Note

The following SCSS code was built using a desktop-first approach, since we are going to progress methodically into mobile-first as we move along in the book.

Here's the SCSS:

//Media Query Mixin - Desktop-first

@mixin forSmallScreens($media) {

@media (max-width: $media/16+em) { @content; }

}

//Nav

.main-nav {

max-width: 980px;

margin: auto;

padding: 10px 5px;

background: #555;

@include forSmallScreens(420) {

padding: 5px 0;

}

//All Navigations

.nav-container {

display: flex;

justify-content: center;

list-style-type: none;

margin: 0;

padding: 0;

@include forSmallScreens(420) {

flex-wrap: wrap;

}

li {

display: flex;

width: 100%;

margin: 0 5px;

text-align: center;

@include forSmallScreens(420) {

display: flex;

justify-content: center;

flex-basis: 45%;

margin: 5px;

}

a {

@extend %highlight-section;

display: flex;

justify-content: center;

align-items: center;

width: 100%;

padding: 10px;

color: white;

}

//Header

.masthead {

display: flex;

justify-content: space-between;

max-width: 980px;

margin: auto;

padding: 10px;

background: #333;

border-radius: 3px 3px 0 0;

@include forSmallScreens(700) {

display: block;

text-align: center;

}

.logo {

@extend %highlight-section;

padding: 0 10px;

color: white;

line-height: 2.5;

@include forSmallScreens(420) {

font-size: .85em;

}

//Search field

.search {

@extend %highlight-section;

padding: 5px;

color: white;

@include forSmallScreens(420) {

font-size: .85em;

}

.field {

width: auto;

margin: 0 10px 0 0;

}

button {

@include forSmallScreens(420) {

width: 100%;

margin-top: 10px;

}

//Main Container

.main-container {

max-width: 980px;

margin: auto;

padding: 10px;

background: #999;

border-radius: 0 0 3px 3px;

}

//Article

.article-container {

@extend %highlight-section;

margin-bottom: 20px;

padding: 10px;

}

//Main Content of the Page

.main-content {

@extend %highlight-section;

width: 75%;

margin-right: 10px;

padding: 10px;

@include forSmallScreens(600) {

width: 100%;

}

h1 {

margin: 0;

}

//Side Content

.side-content {

@extend %highlight-section;

width: 25%;

padding: 10px;

font-size: .8em;

background: #999;

@include forSmallScreens(600) {

width: 100%;

margin-top: 12px;

}

h2 {

margin: 0;

}

ol {

padding-left: 20px;

}

a {

color: #eee;

}

//Contact Form

.contact-form {

@extend %highlight-section;

width: 540px;

margin: 0 auto 20px;

padding: 20px;

@include forSmallScreens(600) {

width: 100%;

}

h2 {

margin-top: 0;

}

label, button {

display: block;

}

.comments {

height: 100px;

}

.flex-container {

justify-content: space-between;

@include forSmallScreens(600) {

display: flex;

}

@include forSmallScreens(400) {

display: block;

}

.label-col {

width: 48%;

@include forSmallScreens(400) {

width: 100%;

}

//Form Elements

.field,

.comments {

width: 100%;

margin-bottom: 10px;

padding: 5px;

@include forSmallScreens(420) {

width: 100%;

}

//Footer

.main-footer {

color: white;

padding: 10px;

background: #333;

p {

margin-top: 0;

}

//Placeholder

%highlight-section {

border: white 1px solid;

border-radius: 3px;

background: rgba(white, .1);

}

//Helper Classes

.flex-container {

display: flex;

@include forSmallScreens(600) {

display: block;

}

//General

*:before,

*:after {

box-sizing: border-box;

}

body {

font-family: Arial, "Helvetica Neue", Helvetica, sans-serif;

}

blockquote {

font-style: italic;

}

Output screenshots for desktop and mobile

The following screenshots represent a prototype/demo both in the wireframe and styled modes. You'll be able to see both the desktop (980-pixels wide) as well as mobile (320-pixels wide) outputs.

In the wireframe screenshots, the white outlines and the gray backgrounds in different tones are basically visual cues to help you understand where the boundaries of each element are without having to use a browser's DevTools.

The styled screenshots, on the other hand, show you what can be accomplished with a small does of CSS. Both the wireframe and styled pages use exactly the same markup.

The demos of the pages can be seen here:

· Visit http://codepen.io/ricardozea/pen/717c6ab2dab9646f814f0429153a6777 for the wireframe page

· Visit http://codepen.io/ricardozea/pen/244886bac2434369bd038294df72fdda for the styled page

Let's see the screenshots.

The desktop output [wireframe] is as follows:

Output screenshots for desktop and mobile

The desktop output [styled] is as follows:

Output screenshots for desktop and mobile

The mobile output [wireframe] is as follows:

Output screenshots for desktop and mobile

The mobile output [styled] is as follows:

Output screenshots for desktop and mobile

Summary

This was a short chapter but it was certainly full of important information.

We learned that HTML is markup and not code. We also saw various HTML5 elements in action. This will help us understand which HTML5 elements can be used to markup the content we are provided with.

We also learned how to mark your HTML with ARIA roles to make our sites/apps more accessible for users with assistive technologies.

We also addressed a few important meta tags that will help your pages and markup display correctly on different devices, and trigger the latest HTML and JavaScript engines in Internet Explorer.

Finally, we saw all the aforementioned topics implemented in an actual full HTML5 example together with its SCSS. The example was built using the desktop-first approach; this will allow us to methodically transition our mental model to the mobile-first technique.

The next chapter is going to be about demystifying when and how to use the mobile-first and/or desktop-first approaches, and how to work with each methodology. Take out your crystal balls!