HTML5 Features

"HTML5" names a set of capabilities that arrived in markup rather than in a library: media without a plugin, form validation without a script, graphics without an image file, and several interactive elements that previously took a few hundred lines of JavaScript each.

They are worth a tour in one place, because the usual way to discover them is to build the hand-made version first.

dialog

A real modal dialog, with the behaviour that is hard to get right by hand.

<dialog id="confirm">
  <form method="dialog">
    <h2>Delete this draft?</h2>
    <p>This cannot be undone.</p>
    <button value="cancel">Keep it</button>
    <button value="delete">Delete</button>
  </form>
</dialog>

<button type="button" onclick="document.getElementById('confirm').showModal()">
  Delete draft
</button>

Opened with showModal(), a dialog does four things a hand-built overlay usually forgets: it traps focus inside itself, it makes everything behind it inert so a click or a Tab cannot reach it, it closes on Escape, and it gets a backdrop you can style with ::backdrop.

method="dialog" on a form inside it is the neat part: submitting closes the dialog without navigating anywhere, and the pressed button's value is available afterwards as the dialog's returnValue.

Two notes. show() opens it non-modally, without the focus trap, which is usually not what you want. And the element needs a heading or an aria-label, or it is announced as an unnamed dialog.

template

Markup the browser parses but does not render.

<template id="course-card">
  <article class="card">
    <h3 class="title"></h3>
    <p class="summary"></p>
    <a class="link" href="#">Explore</a>
  </article>
</template>

<ul id="courses"></ul>

Everything inside a template is parsed into a document fragment and stays inert: images are not fetched, scripts do not run, styles do not apply, and nothing appears on the page. A script clones it with template.content.cloneNode(true), fills in the blanks and inserts the copy.

The alternative is building HTML by string concatenation in JavaScript, which is both harder to read and the usual route to an injection bug. A template keeps the markup in the markup.

details and summary

Covered in the semantics lesson and worth repeating here as a feature rather than as a semantic: a disclosure widget with no script.

<details>
  <summary>Show the full specification</summary>
  <p>The content appears when the summary is activated, and the browser
     handles the keyboard, the focus and the announcement.</p>
</details>

canvas

A drawing surface. The element itself is two attributes and an empty box; everything that appears on it is drawn by script.

<canvas id="sparkline" width="300" height="80">
  Enrolments rose steadily through the year, from 40 in January to 290 in December.
</canvas>

The text inside is the fallback, and it is the part people miss. A canvas is a bitmap: there are no elements inside it, so a screen reader has nothing whatever to read. Whatever the drawing communicates has to be available in the markup as well, either as that fallback content or as a table nearby.

Use canvas for things that change every frame - a game, a visualisation of thousands of points, video processing. For anything static or interactive, SVG is usually the better answer.

Inline SVG

Vector graphics written as markup, so they are elements like any others.

<figure>
  <svg width="220" height="90" viewBox="0 0 220 90" role="img"
       aria-label="Enrolments rose from 40 in January to 290 in December">
    <polyline points="10,80 60,62 110,45 160,28 210,12"
              fill="none" stroke="currentColor" stroke-width="3"></polyline>
    <circle cx="210" cy="12" r="4" fill="currentColor"></circle>
  </svg>
  <figcaption>Enrolments, January to December</figcaption>
</figure>

Because the shapes are elements, CSS can style them and scripts can attach events to them. stroke="currentColor" inherits the surrounding text colour, so the chart follows a dark mode without any extra work. viewBox is what makes it scale: it defines the coordinate system, and the width and height then just say how big to draw it.

role="img" with aria-label gives the whole graphic a single text alternative. Without them, a screen reader may try to read the individual shapes, which is noise.

Media, in one line

<p>
  <audio controls src="lesson.mp3">
    Your browser cannot play audio.
  </audio>
</p>

Audio and video are covered properly in the next lesson. The point here is the contrast: embedding media used to mean a plugin, an object tag and a fallback chain. It is now one element with a controls attribute.

Two more that save a script each

<p>
  <label for="upload">Uploading</label>
  <progress id="upload" value="64" max="100">64%</progress>
</p>

<p>
  <label for="disk">Disk used</label>
  <meter id="disk" value="0.82" low="0.5" high="0.8" optimum="0.2">82%</meter>
</p>

<p>
  <label for="browser">Browser</label>
  <input id="browser" name="browser" type="text" list="browser-options">
  <datalist id="browser-options">
    <option value="Chrome"></option>
    <option value="Firefox"></option>
  </datalist>
</p>

progress is a task advancing towards completion - an upload, an install. Omit value and it becomes an indeterminate spinner, which is the right thing when you genuinely do not know how long is left.

meter is a measurement within a known range, which is a different idea: disk usage, a score, a temperature. low, high and optimum let the browser colour it, and optimum is what tells it which end is good - so a meter where low values are better is expressed rather than inverted by hand.

The text inside each is the fallback for a browser that does not render them.

Obsolete elements

The other half of "modern HTML" is what has been retired.

They mostly still render, because browsers do not break old pages. That is not a reason to write new ones: each puts presentation back into the markup layer, and frameset additionally breaks bookmarking, the Back button and search indexing.

Checking support

Features arrive at different times in different browsers, and the reliable answer to "can I use this?" is a compatibility table rather than a specification - the specification says what should exist, the table says what does.

The markup-level fallback pattern is worth knowing, because it is built into most of these elements. A canvas falls back to its contents. A video falls back to its contents. A picture falls back to its img. An unknown element renders as an inline box with its contents visible, which is why a dialog in a very old browser shows its content rather than hiding it - and why dialog is one to feature-detect before relying on.

Practice task

Build a page with a details FAQ, a dialog that confirms an action, and an inline svg icon that inherits the text colour. Open the dialog and press Escape, then Tab repeatedly and confirm focus never leaves it. Then look at the canvas example above and write the fallback sentence you would need if the drawing were a real chart - that sentence is what a screen reader user gets, and writing it is usually the moment you realise what the chart is actually for.