Book Image

Responsive Web Design with HTML5 and CSS - Third Edition

By : Ben Frain
Book Image

Responsive Web Design with HTML5 and CSS - Third Edition

By: Ben Frain

Overview of this book

Responsive Web Design with HTML5 and CSS, Third Edition is a renewed and extended version of one of the most comprehensive and bestselling books on the latest HTML5 and CSS tools and techniques for responsive web design. Written in the author's signature friendly and informal style, this edition covers all the newest developments and improvements in responsive web design including better user accessibility, variable fonts and font loading, CSS Scroll Snap, and much, much more. With a new chapter dedicated to CSS Grid, you will understand how it differs from the Flexbox layout mechanism and when you should use one over the other. Furthermore, you will acquire practical knowledge of SVG, writing accessible HTML markup, creating stunning aesthetics and effects with CSS, applying transitions, transformations, and animations, integrating media queries, and more. The book concludes by exploring some exclusive tips and approaches for front-end development from the author. By the end of this book, you will not only have a comprehensive understanding of responsive web design and what is possible with the latest HTML5 and CSS, but also the knowledge of how to best implement each technique.
Table of Contents (14 chapters)
12
Other Books You May Enjoy
13
Index

New semantic elements in HTML5

My dictionary defines semantics as "the branch of linguistics and logic concerned with meaning." For our purposes, semantics is the process of giving our markup meaning. Why is this important?

Most websites follow fairly standard structural conventions; typical areas include a header, a footer, a sidebar, a navigation bar, and so on. As web authors, we will often name the div elements we use to more clearly designate these areas (for example, <div class="Header">). However, as far as the code itself goes, any user agent, and that includes a web browser, screen reader, or search engine crawler, parsing that content couldn't say for sure what the purpose of each of these div elements is. HTML5 solves that problem with new semantic elements.

For the full list of HTML5 elements, get yourself (very) comfy and point your browser here: http://www.w3.org/TR/html5/semantics.html#semantics.

We won't cover every one of the new elements here, merely those I feel are the most beneficial or interesting in day-to-day responsive web design use. After we have gone through the elements and gained an understanding of their intended use, we will look at some content examples, and consider how they might be best marked up. Then, to end the chapter I'm going to set you a bigger challenge!

In terms of the HTML specification, the elements we will be looking at fall into one of three groups:

  • Sectioning elements, for the broadest strokes in a HTML page. These are the kind of elements to use for header, footer, and sidebar areas.
  • Grouping elements, which are used to wrap associated elements. Think of paragraphs, blockquotes, and content of that nature.
  • Text-level semantics, which are the elements we use to designate particulars, like a section of bold or italic text or code.

We will now look at the most useful from each of these sections in turn.

The <main> element

For a long time, HTML5 had no element to demarcate the main content of a page. It was argued that the content that wasn't inside one of the other new semantic HTML5 elements would, by negation, be the main content. Thankfully, we now have a more declarative way to group the main content: the aptly named <main> tag. Whether you're wrapping the main content of a page or the main section of a web-based application, the main element is what you should be grouping it all with. Here's a particularly useful line from the specification:

The main content area of a document includes content that is unique to that document and excludes content that is repeated across a set of documents such as site navigation links, copyright information, site logos and banners and search forms (unless the document or application's main function is that of a search form).

It's also worth noting that there shouldn't be more than one main on each page (after all, you can't have two main pieces of content) and it shouldn't be used as a descendent child element of some of the other semantic HTML5 elements, such as article, aside, header, footer, nav, or header.

Read the official line on the main element at http://www.w3.org/TR/html5/grouping-content.html#the-main-element.

The <section> element

The <section> element is used to define a generic section of a document or application. For example, you may choose to create sections around your content: one section for contact information, another section for news feeds, and so on. It's important to understand that it isn't intended for styling purposes.

If you need to wrap an element merely to style it, you should continue to use a div as you would have before.

When working on web-based applications, I tend to use section as the wrapping element for visual components. It provides a simple way to see the beginning and end of components in the markup.

You can also qualify for yourself whether you should be using a section based upon whether the content you are sectioning has a natural heading within it (for example, an h1-h6). If it doesn't, it's likely you'd be better off opting for a div.

To find out what the W3C specification says about <section>, go to the following URL: http://www.w3.org/TR/html5/sections.html#the-section-element.

The <nav> element

The <nav> element is used to wrap major navigational links to other pages or parts within the same page. As it is for use in major navigational blocks it isn't strictly intended for use in footers (although it can be) and the like, where groups of links to other pages are common. If you usually mark up your navigational elements with an unordered list (<ul>) and a bunch of list tags (<li>), you may be better served with a nav and a number of nested <a> tags instead.

To find out what the W3C specification says about <nav>, go to the following URL: http://www.w3.org/TR/html5/sections.html#the-nav-element.

The <article> element

The <article> element, alongside <section>, can easily lead to confusion. I certainly had to read and re-read the specifications of each before it sank in. Here's my reiteration of the specification. The <article> element is used to wrap a self-contained piece of content. When structuring a page, ask whether the content you're intending to use within an <article> tag could be taken as a whole lump and pasted onto a different site and still make complete sense. Another way to think about it is, would the content that you are considering wrapping in an <article> actually constitute a separate article in an RSS feed? Obvious examples of content that should be wrapped with an <article> element would be blog posts or news stories. Be aware that if you are nesting <article> elements, it is presumed that the nested <article> elements are principally related to the outer article.

You can read the specification for the <article> element here: http://www.w3.org/TR/html5/sections.html#the-article-element.

The <aside> element

The <aside> element is used for content that is tangentially related to the content around it. In practical terms, I often use it for sidebars, or content as a little tip about a related subject in a blog post. It's also considered suitable for pull quotes, advertising, and groups of navigation elements; basically, anything not directly related to the main content would work well in an aside. If it was an e-commerce site, I'd consider areas like "Customers who bought this also bought" as prime candidates for an <aside>.

For more on what the W3C specification says about <aside>, visit http://www.w3.org/TR/html5/sections.html#the-aside-element.

The <header> element

Practically, the <header> can be used for the "masthead" area of a site's header but also as an introduction to other content, such as an introduction section within an <article> element. You can use it as many times on the same page as needed. You could have a <header> inside every <section> on your page for example.

Here's what the W3C specification says about <header>: http://www.w3.org/TR/html5/sections.html#the-header-element.

The <footer> element

Like the <header>, the <footer> element doesn't take part in the outline algorithm (more on that in the following section) so doesn't section content. Instead it should be used to contain information about the section it sits within. It might contain links to other documents or copyright information, for example. Like the <header>, it can be used multiple times within a page if needed. For example, it could be used for the footer of a blog but also a footer within a blog post <article>.

However, the specification notes that contact information for the author of a blog post should instead be wrapped by an <address> element.

The W3C specification for the <footer> element can be found here: http://www.w3.org/TR/html5/sections.html#the-footer-element.

The HTML5 outline algorithm

Ordinarily, for an HTML document, headings would begin with an h1 for the main page title and then progress to using lower hierarchy title tags as needed for subheadings and the like.

However, HTML5 introduced the ability for each sectioning container to have its own self-contained outline. That means it is not necessary to think about which level of heading tag you're at in terms of the entire document. You could just concentrate on the sectioning container you are currently working in.

To illustrate why this might be preferable, within a blog, post titles could be set to use <h1> tags, while the title of the blog itself could also have an <h1> tag. For example, consider the following structure:

<h1>Ben's site</h1>
<section>
  <h1>Ben's blog</h1>
  <p>All about what I do</p>
</section>
<article>
  <header>
    <h1>A post about something</h1>
    <p>Trust me this is a great read</p>
    <p>No, not really</p>
    <p>See. Told you.</p>
  </header>
</article>

Despite having multiple <h1> headings, the outline still appears as follows:

  1. Ben's site
  2. Ben's blog
  3. A post about something

As such, theoretically you shouldn't need to keep track of the heading tag you need to use in terms of the whole document. It should be possible to use whatever the appropriate level of heading tag is needed within each piece of sectioned content and the HTML5 outline algorithm will order it accordingly.

You can test the outline of your documents using HTML5 outliners at one of the following URLs:

However, the reality is that search engines and the like make no use of the HTML5 outliner at present. Therefore, from a pragmatic standpoint, it probably makes more sense to continue thinking about headings in terms of the whole document. That will make your documents easier to read for search engines and also aid assistive technology to infer the correct meaning.

A note on h1-h6 elements

Something I wasn't aware of initially is that using h1-h6 tags to mark up headings and subheadings is discouraged. I'm talking about this kind of thing:

<h1>Scones:</h1>
<h2>The most resplendent of snacks</h2>

Here's a quote from the HTML5 specification:

h1–h6 elements must not be used to mark up subheadings, subtitles, alternative titles and taglines unless intended to be the heading for a new section or subsection.

That's us told!

So, how should we author such content? The specification actually has a whole section, http://www.w3.org/TR/html5/common-idioms.html#common-idioms, dedicated to this. Personally, I preferred the old <hgroup> element, but sadly that has been deprecated (more info in the Obsolete HTML features section). So, to follow the advice of the specification, our prior example could be rewritten as:

<h1>Scones:</h1>
<p>The most resplendent of snacks</p>

Right, we've now covered the lion's share of the HTML sectioning elements. Let's now consider grouping elements.

The div element

The most ubiquitous grouping element is the <div>. The <div> is so widely used because it is opinion-less. It conveys nothing. The only implied meaning of a div is that it groups something. Despite that, you will often see a div wrapping nothing but a string of text.

You should only opt for a div as a last resort. It is the element to use when you can think of nothing better.

We have more elements in HTML than ever before, so as we continue, hopefully we will get acquainted with plenty of other elements that will be more suitable for the jobs you currently use a div for.

The p element

The <p> element is used to markup a paragraph. However, don't think that means it can only be used on text 3-4 lines long. On the contrary, use it to mark up any text that cannot be better marked up with one of the other elements. For non-specific text, the p element is definitely a better choice than a div.

The blockquote element

A blockquote is used to markup text that is quoted from somewhere else. You don't have to wrap the text with any other element, but you can. For example, knowing what we now do about the p tag, we can use that inside a blockquote too if we wish. Here is a simple example using blockquote. First, there's an introductory section of text in a p tag, and then a blockquote:

<p>I did like Ben's book, but he kept going on about scones. For example:</p>
<blockquote>
All this writing about scones in our sample page and there's no image of the beauties! I'm going to add in an image of a scone near the top of the page; a sort of 'hero' image to entice users to read the page.
</blockquote>

There's some good examples of how and when to use blockquotes over on the HTML specification too: https://html.spec.whatwg.org/multipage/grouping-content.html#the-blockquote-element.

The <figure> and <figcaption> elements

The HTML specification relates that the <figure> element:

...can thus be used to annotate illustrations, diagrams, photos, code listings, etc.

So we use it as an element to call out visuals of any sort, and the accompanying <figcaption> provides the means to add some text supporting the visuals. Now, it is worth pointing out here that while we should always provide text in the alt attribute of an <img> tag to support assistive technology or to mitigate problems if an image fails to load, it isn't a requirement to provide a figcaption with a figure. The figcaption is added if you want to add a visual description alongside the visuals. Here's how we could use it to revise a portion of markup from the first chapter:

<figure class="MoneyShot">
  <img
    class="MoneyShotImg"
    src="img/scones.jpg"
    alt="Incredible scones baked to perfection and ready to eat"
  />
  <figcaption class="ImageCaption">
    This image isn't of scones I have made, instead it's a stock photo from Wikipedia
  </figcaption>
</figure>

You can see that the <figure> element is used to wrap this little self-contained block. Inside, the <figcaption> is used to provide a caption for the parent <figure> element.

It's perfect when images or code need a little caption alongside them (that wouldn't be suitable in the main text of the content).

The specification for the figure element can be found here: http://www.w3.org/TR/html5/grouping-content.html#the-figure-element. The specification for the figcaption is here: http://www.w3.org/TR/html5/grouping-content.html#the-figcaption-element.

<details> and <summary> elements

How many times have you wanted to create a simple open and close widget on your page? A piece of summary text that when clicked, opens a panel with additional information? Modern HTML facilitates this pattern with the details and summary elements. Consider this markup (you can open example3.html from this chapter's code to play with it for yourself):

<details>
  <summary>I ate 15 scones in one day</summary>
  <p>
    Of course I didn't. It would probably kill me if I did. What a way to go.
    Mmmmmm, scones!
  </p>
</details>

Opening this in Chrome, with no added styling, shows only the summary text by default:

Figure 2.1: <details> and <summary> attempt to solve a common problem but their implementation is limited

Clicking anywhere on the summary text opens the panel. Clicking it again toggles it shut. If you want the panel open by default you can add the open attribute to the details element:

<details open>
  <summary>I ate 15 scones in one day</summary>
  <p>
    Of course I didn't. It would probably kill me if I did. What a way to go.
    Mmmmmm, scones!
  </p>
</details>
A screenshot of a social media post

Description automatically generated

Figure 2.2: By adding the open attribute, the content is shown by default

Supporting browsers typically add some default styling to indicate the panel can be opened. Here in Chrome (and also Safari) that's a dark disclosure triangle. Different browsers have their own implementations of how we can deal with any marker for the details. As this is typically not a selector that has been defined in any W3C specification, to disable it in this instance, you need to use a proprietary pseudo class (note the -webkit- prefix):

summary::-webkit-details-marker {
  display: none;
}

You can of course use that same selector to style the marker differently.

Currently, there is no way of animating the open and close. Without JavaScript, there's also no way of toggling other details panels closed when another details/summary combination is open. I'm not sure either of these desires will (or should) ever be addressed. However, I've therefore found the usefulness of these elements pretty limited by themselves. Rather than an all-in-one open/close drawer solution, you should think of them as a way to more semantically facilitate what you would have done previously with a display: none; toggle on a standard div with the help of JavaScript.

The <address> element

The <address> element is to be used explicitly for marking up contact information for its nearest <article> or <body> ancestor. To confuse matters, keep in mind that it isn't to be used for postal addresses and the like (unless they are indeed the contact addresses for the content in question). Instead, postal addresses and other arbitrary contact information should be wrapped in good ol' <p> tags. I'm not a fan of the <address> element. In my experience it would be far more useful to mark up a physical address with this element. However, hopefully it makes more sense to you.

For more on what the W3C specification says about <address>: http://www.w3.org/TR/html5/sections.html#the-address-element.

We have now covered the majority of the sectioning elements of HTML. We will now move on to the text-level elements. These are the elements used to mark up individual words, letters, and symbols to provide explicit meaning as to the intent.