Introduction
This document touches on some of the lesser used HTML elements. Most can be done quite effectively with old school elements like <p>, <div>, <span>, <pre>, and<>.
Most were introduced in version 5 of HTML (HTML5), for the purpose of being more semantic.
Definition
For the purposes of this document, semantic means pertaining to the element name's context or usage rather than the element's appearance.
New semantic element name |
Old semantic method |
|
<menu> | <div class="menu"> for vertical, <span class="menu"> for horizontal, |
|
<nav> | <div class="nav"> | |
<code> | <span class="code"> | |
<abbr> | <span class="abbr"> | |
<cite> | <span class="cite"> |
Use Well Formed XML
The HTML5 spec allows, but does not insist on, your HTML also being well formed XML. In other words, using end tags.
I recommend always making your HTML5 well formed XML because doing so makes it ten times as easy to create valid HTML that renders the same everywhere. Using XMLized HTML5 also relieves you from being an HTML superguru because your end tags define where elements end, instead of the intricate, arcane and inadequately documented rules of HTML governing where elements end. XMLized HTML5 is much easier to debug all the way to zero error, zero warning validation testing. And of course zero error and zero warning validation means that all quality browsers render your page basically the same.
I made a trivially simple Python program to test whether a file is well formed XML. It takes about 1/8 second to run. Once a file is well formed XML, it's very likely to be valid HTML5, and if it's not, it's pretty easy to resolve any remaining problems. And if I wanted to, I could improve my Python program to produce a better report.
For the past 2 years, I've always used version 5 of HTML (HTML5), and I've always made my HTML5 files also be well formed XML. You should do the same.
Most quality Zen-Coding editors insert the end tags when you insert the begin tags, so making your HTML5 conform to well formed XML isn't much more typing. I always
Styles Based Authoring
Styles Based Authoring (SBA from now on) is a document construction technique in which strings or whole paragraphs of the document source are assigned styles, and separately, the styles are assigned appearances.
It's called styles-based authoring because instead of willy-nilly applying appearances to text, the styles-based author puts the text one place, the appearances another place, and uses styles to interface between the text and appearances:
- Appearances are applied to styles.
- Styles are applied to text.
The following graphic illustrates how styles-based authoring works:
Appearance is applied to the style, which applies appearance to the content based on context. For HTML documents, styles are created in CSS.
The willy-nilly appearance approach almost always leads to documents with inconsistent appearances; e.g. book titles that are italic some places, bold other places, and dark green still other places. Such inconsistency confuses readers.
Another problem that crops up with the willy-nilly approach occurs when you decide to change the appearance of a certain type of text. For instance, if all your book titles are italic, but now you want to make them dark green instead, you need to find every instance of italic text, decide whether it's describes a book cover, and if so, change it to dark green. And if tomorrow you decide to change your book titles to bold instead of dark green, you have to go through all of this again.
<video>
A lot of people, myself included, think that the <video>
element is the greatest improvement in HTML5, and believe me, HTML5 has a lot of improvements. The <video> element enables any old halfway standard audio file to be streamed. Capable browsers now have this streaming capability on seeing a valid <video> element.
This represents a huge leap forward. Before HTML5, playing a video involved one of three things:
- Download then play on a dedicated player, or
- Use that awful proprietary closed source Flash Video, or
- Navigate the strange, difficult and proprietary world of Realaudio.
That was then, this is now. The following code plus result shows how incredibly easy it is to put a streaming video on your web page. And believe me, it streams. That video is well over 20MB, yet it starts in an instant.
<video controls> <source src="video/band.mp4" type="video/mp4"> video>
The <video>
element can take multiple sources, so if one doesn't work, the next one can try. The multiple sources can even be of the same file, but with different file codecs, etc.
The <video>
element has the preload
property, which, if specified, can be set to none
, metadata
or auto
.
none
means don't play the clip until the whole thing is downloaded. The only purpose I see for this is to inconvenience the user, unless a significant number of users are expected to be on such slow lines connections that the video would keep starting and stopping. Remember dialup?
metadata
is what I use. It loads the metadata and then stops until the video is requested to play. The metadata, including video length, makes the streaming download easier and faster, making the rest of the streaming easier on the connection, browser and computer.
auto
means start loading the video when loading the page. I'm not a fan. It's a waste of the Internet's bandwidth, and on slow connections it slows the web experience for the sake of a video the visitor might not even want to see.
The <video>
element has other attributes. The following list shows some of them:
- controls: Specifies whether or not to put controls on the video's window. I can't think of a reason not to.
- controlslist: This specifies which controls to put on the video's window.
- height: Specifies the window's height in CSS pixels, not percentages or
em
. - loop: Specifies that the video plays over and over again.
- muted: Specifies that the video window starts up muted, so the visitor has the option of turning the sound on or leaving it off. This is a bad idea on short clips because the visitor won't have time to turn it off.
- src: Instead of using this attribute, use the
<source>
child element instead.
This section has barely scratched the surface of the <video>
element. Do more research as necessary.
<audio>
The <audio>
provides a nice way to stream an audio file. It has pretty much the same attributes as the <video>
element described previously in this document. It's customary to have it contained in a <figure> element, with a <figcaption> element to describe the audio being played. The following shows HTML code and results of a <audio>
sample.
<figure> <figcaption>Sample audio clip:</figcaption> <audio src="audio/pinecrest.wav" controls></audio> </figure>
<figure>
and <figcaption>
The <figure>
element provides a standard way to contain a figure and its caption. I seldom use it because my figures come immediately after "the following figure ...:", but you may find it very handy. It typically contains two child elements, an image of some kind and a <figcation>
element containing the figure's caption.
<address>
This element provides a standard and consistent way to format addresses. It can also be used for contact info such as email address, contact website, and phone number. It can be styled as desired with CSS. Each line must be terminated with <br/>
, or the whole address runs together. The following is an example:
888 Happiness Highway
Bliss, CA, 90000
(555) 555-5555
The more addresses or contact info you have in your documents, the more important this element becomes.
<bdi>
and <bdo>
These elements are used for languages read from right to left. If you have need of this, familiarize yourself with these elements.
<meter>
This element is a great way to graphically represent a quantity with a maximum, minimum, and current value.
<label>Fuel level (21):</label> <meter id="fuel" min="0" max="100" low="25" high="80" optimum="90" value="21"> </meter><br/> <label>Fuel level (50):</label> <meter id="fuel" min="0" max="100" low="25" high="80" optimum="90" value="50"> </meter><br/> <label>Fuel level (85):</label> <meter id="fuel" min="0" max="100" low="25" high="80" optimum="90" value="85"> </meter><br/>
<code>
Very, VERY nice. It's used to signify inline code. Where's this been all my life?
For the past ten years I've been using <span class="code">
for this purpose. <code>
is just as semantic, just as Styles Based Authoring compliant, and less typing, which is wonderful for such a frequent tag.
<nav>
This represents a section of a page showing a set of navigational links on page or off page. to provide navigation links, either within the current document or to other documents. Common examples of navigation sections link lists to other pages, tables of contents, and indexes. This element helps people using a reader, and it provides an opportunity to give all navigation sets a consistent appearance.
By putting <nav></nav> tags around a set of navigation links, you give the visually handicapped person using an HTML reader the clue that this whole section is links. Secondarily, you can set the appearance of the <nav> element to make your navigational links distinct from other content yet uniform among themselves.
Because <nav> elements contain many links, and because links typically have carefully set colors for click, hover, visited and unvisited, you should be careful about changing colors for <nav>. Changing the foreground color would require also changing the visited, unvisited, hovered and clicked state colors. If you change the background color, the foreground colors must contrast with it. Please remember that red/green color blindness is very common, so never make distinctions between red and green.
Example: Nav Section
WARNING:
Some examples of <nav>
sections use buttons as links. This is a bad idea.Wrapping a button in <a>
<a>
triggers an error on the W3C validator. Other ways to do it are non-semantic, misleading, and can lead to confusion for those with screen readers. And remember, people in general expect buttons to take an action, not to follow a link.
<kbd>
I think, but am not sure, that this element is used in command line interface interactions to signify what the user typed in, as opposed to what the program output. Until now I've been using <span class="userinput">
. I might make the switch in the future.
Whether or not <kbd>
renders in a typewriter font is left to the browser, so I'd suggest strongarming it to a typewriter font with CSS.
<gt;, <gt;, and <gt;
<dl>
Represents a description list. The element encloses a list of groups of terms (specified using the <dt> element) and descriptions (provided by <dd> elements). Common uses for this element are to implement a glossary or to display metadata (a list of key-value pairs).
<dt>
Specifies a term in a description or definition list, and as such must be used inside a <dl> element. It is usually followed by a <dd> element; however, multiple <dt> elements in a row indicate several terms that are all defined by the immediate next <dd> element.
<dd>
Provides the description, definition, or value for the preceding term (<dt>) in a description list (<dl>).
Not a Fan
This section mentions elements I don't use and consider of negligible value.
<big>
: Deprecated for a good reason: It's confusing and stateful. Specify font size explicitly, for every style, with CSS.<frame>
and<frameset>
: The darling look of 1998, these atrocities should have never happened, but at least now, over 20 years later, they're finally deprecated.<i>
: Originally standing for "italic", this element describes an appearance, not a context. Use<em>
. Or if the purpose of italics aren't emphasis, make a new<span>
class, with the class name revealing the usage and context.<b>
: Originally standing for "bold", this element describes an appearance, not a context. Use<strong>
. Or if the purpose of bold isn't emphasis, make a new<span>
class, with the class name revealing the usage and context.<mark>
: Definition of when to use it is too vague and too broad. To achieve Styles Based Authoring, I recommend a special, aptly named class of<span>
instead.<section>
: See this section's special section for <section><Z>
:<Z>
:<Z>
:<Z>
:<Z>
:<Z>
:<Z>
:<Z>
:<Z>
:<Z>
:<Z>
:<Z>
:<Z>
:<Z>
:
<section>
To almost quote the Mozilla Developer Network (MDN) docs on <section>
: The <section>
HTML element represents a generic standalone section of a document, which doesn't have a more specific semantic element to represent it. Sections should always have a heading, with very few exceptions." What does that all even mean?
How do I dislike this? Let me count the ways. First, where do you put the heading, and what style do you use for it, and is it inside or outside of the <section>
container? Unclear.
Also not mentioned is how deep in the H1 through H6 hierarchy you need to use sections. Examples on the MDN web pages and elsewhere show sections at descending levels. So sections within sections within sections. That spells a lot of added complexity, both in the document's DOM hierarchy, and for the human reading the HTML?
And what does it really gain for you? Not a whole lot. The blind person with a reader can deduce sections just like a sighted person: By the H1-H6 hierarchy. Correct use of <section>
elements can ease conversion of HTML to ePub eBooks or Beamer presentations, but incorrect usage from mistakes is easy and would mess up the eBook or presentation. I guess theoretically we're now supposed to use <section>
, but I won't be doing it without massive reasons to use it. The H1-H6 hierarchy is good enough for me.
<mark>
To quote from the Mozilla Developer Network page on <mark>
"Represents text which is marked or highlighted for reference or notation purposes due to the marked passage's relevance in the enclosing context."
Say what? Seriously, the preceding "definition" tells me nothing about when to use it, so I won't.
This concludes the material for this page. Everything below here is under construction and change and likely inaccurate.
The Elements
<address>
<article>
<aside>
<footer>
<header>
<hgroup>
Represents a heading grouped with any secondary content, such as subheadings, an alternative title, or a tagline.
<search>
Represents a part that contains a set of form controls or other content related to performing a search or filtering operation.
<blockquote>
Indicates that the enclosed text is an extended quotation. Usually, this is rendered visually by indentation. A URL for the source of the quotation may be given using the cite attribute, while a text representation of the source can be given using the <cite>
element.
<menu>
A semantic alternative to <ul>, but treated by browsers (and exposed through the accessibility tree) as no different than <ul>. It represents an unordered list of items (which are represented by <li< elements).
<abbr>
Represents an abbreviation or acronym.
<b>
Bold. Not semantic, but rather describes appearance. I'm not a fan. I never use it. I use <strong>, or else I make a new class of <span>.
<bdi>
Tells the browser's bidirectional algorithm to treat the text it contains in isolation from its surrounding text. It's particularly useful when a website dynamically inserts some text and doesn't know the directionality of the text being inserted.
<bdo>
Overrides the current directionality of text, so that the text within is rendered in a different direction.
<cite>
Used to mark up the title of a cited creative work. The reference may be in an abbreviated form according to context-appropriate conventions related to citation metadata.
<data>
Links a given piece of content with a machine-readable translation. If the content is time- or date-related, the<time>
element must be used.
<dfn>
Used to indicate a term being defined. within the context of a definition phrase or sentence. The ancestor <p> element, the <dt>/<dd> pairing, or the nearest section ancestor of the dfn
element, is considered to be the definition of the term. The following is an example:
- HTML: The markup language used to create most websites.
- CSS: Stands for Cascading Style Sheets, it's the language that acts to convert semantic styles into appearances.
- The word semantic means referring to the underlying context or meaning, and not to appearance.
In the preceding example, I put the strings "HTML", "CSS" and "semantic" inside a <dfn>dfn</dfn>
pair.
<em>
Marks text that has stress emphasis. The <em> element can be nested, with each nesting level indicating a greater degree of emphasis.
<i>
Italic. Not semantic, but rather describes appearance. Use <em>
instead of this silly thing.
<kbd>
Represents a span of inline text denoting textual user input from a keyboard, voice input, or any other text entry device. By convention, the user agent defaults to rendering the contents of a kbd
element using its default monospace font, although this is not mandated by the HTML standard.
<q>
Indicates that the enclosed text is a short inline quotation. Most modern browsers implement this by surrounding the text in quotation marks. This element is intended for short quotations that don't require paragraph breaks; for long quotations use the <blockquote> element.
<s>
Strikethrough: Text crossed out by a line through it's center. The <s> element is used for things that are no longer relevant or no longer accurate. However, it is not appropriate when for document edits. For document edits, use the <del>
and <ins>
elements for document edits
<s> is not semantic, but rather describes appearance. I'd suggest creating <span class="deleted"> instead.
<samp>
As a practical matter, <samp>
pretty much duplicates <code>
. Both can be used to represent inline source code such as variables, or inline output of a program. Theoretically, <samp>
should be used for program output and <code>
should be used for things like variables in a program. They are both rendered monospace in most browsers.
I can think of one very cool use of <samp>
. When you show a command on the command line and its output, you can wrap the command with <samp>
and </samp>
to give the command a distinct appearance, so the reader can differentiate between commands and output. This becomes very necessary when showing several commands with output in one session. In order to show a distinct appearance, you need to create a CSS definition of <samp>
, usually changing the background color.
Up until now, I've used my home-grown <pre class="userinput">
to represent commands in command/output sequences. This has the advantage of being more self-documenting than <samp>
, but it takes more typing. I'll be evaluating whether I want to switch to <samp>
.
<small>
This is an old school tag to describe appearance (smaller text), and is not semantic. I'm not a fan.
<sub>
Subscript. Lowered baseline and smaller text. If there are more than one kind of subscript in your document, for instance, element numbers for a set(N1, N2, N3) as opposed to the quantity of each element in a molecule's chemical formula (H2O, CO2, C2H5OH).
<sup>
Superscript. Raised baseline and smaller text. If there are more than one kind of superscript in your document, for instance, math exponents, copyright and trademark symbols, ordinal numbers like 1st and 2nd, and other superscript uses, you can create different classes for <sup>.