Use the “i” Element, and Use It Appropriately

Published on June 29, 2021 (↻ February 5, 2024), filed under Development (RSS feed for all categories).

“Use em instead of i” is in the Top 25 of bad advice you can get in HTML development. The two elements have different meanings, the blunt rule ignores all context, and, when handed out in the belief that i was deprecated, misses that i is a valid element with legitimate use cases.

In Upgrade Your HTML III, I talk a little more about this element:

<p>In your receipt email, click the <em>View product</em> button and it will take you to a page where you can download the <abbr>PDF</abbr> as well as a text file named <em>sites_using_adobe_fonts.txt</em>. That text file contains the login <abbr>URL</abbr> and password. Additional information is included inside the <abbr>PDF</abbr> on page 4.</p>

Let’s get on thin ice. What crosses your mind when you look at the above code?

1. (Insert your thoughts here)
2. Are the abbr elements useful without a title?
3. Are the em elements used for emphasis?

I’m curious about your thoughts!

For the abbr elements, this is valid! As abbr elements can contain an “abbreviation or acronym, optionally with its expansion,” this all looks good.

Personally—as a purist—, I stopped marking up abbreviations and acronyms in the 2000s, after always meticulously marking up and expanding all of them. My memory tells me I picked this up from Ian Hickson, one of my web development role models and a former colleague.

The title of this chapter gives it away: There’s something off with the em elements. Of course, we can’t tell the intent, so perhaps the author would argue that indeed, they mean emphasis. Yet this emphasis, for a button and a file name, looks more like this use of em was presentational rather than structural. It looks like, perhaps, a different quality of text. For this the HTML specification has an element, and that’s i:

The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts.

What we have here may fit several use cases for i: “View product” seems to warrant an alternate voice or mood, it seems to be of a different quality, and it probably constitutes a form of designation. For “sites_using_adobe_fonts.txt”, it matches another designation and is arguably a technical term.

Let’s go for i elements and, while at it, remove the abbr elements:

<p>In your receipt email, click the <i>View product</i> button and it will take you to a page where you can download the PDF as well as a text file named <i>sites_using_adobe_fonts.txt</i>. That text file contains the login URL and password. Additional information is included inside the PDF on page 4.

Use i, and use it appropriately.

Use and Mention

In philosophy, you make a distinction between using a term and mentioning it—the use–mention distinction.

In this example, the terms we wrapped in i elements are mentioned, rather than used. If you go by this distinction, you would quote the respective terms instead:

<p>In your receipt email, click the “View product” button and it will take you to a page where you can download the PDF as well as a text file named “sites_using_adobe_fonts.txt”. That text file contains the login URL and password. Additional information is included inside the PDF on page 4.

As we’re now left without i elements, and as we didn’t plan for philosophy to tell us what markup to use, I made this only a note.

Check out the other nine chapters—and the Upgrade Your HTML book series (at Amazon, Apple Books, Google Play Books, and Leanpub)!

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)