You’re using〈em〉wrong

It’s been a bumpy road that somehow got us misusing one of the most important text-level semantic tags.

In the dark ages of HTML, <em> was barely used at all, despite being part of the specs since really early on (HTML 2.0 standard, 1995). But at that point in time and for some years to come, (almost) no one was thinking of semantics or even separation of concerns. Italics were simply marked up with <i> tags, and we wouldn’t give it a second thought.

Then somewhere along the way, someone shouted “Semantics!” and everybody started to hate the poor little <i> tag like a bad neighbor. A really, really bad neighbor.

<em> was all the rage, with supposed benefits for accessibility and SEO, which got us all using it everywhere. By HTML 4, everybody knew <em> was for emphasis and styled as italics, <strong> was for stronger emphasis and styled as bold text. If you ever dared to use <i>, you would be instantly tagged as a bad developer.

There were even rumours that the totally un-semantic <i> and <b> would be deprecated any minute like <u> was, and our WYSIWYG editors didn’t even have a button for <i> or <b>, they would simply put an <em> whenever we clicked the italics icon and <strong> when clicking the bold.

But….

The <em> tag is not for emphasis

Let me repeat that: <em> is not for emphasis. In HTML5, <em> is for stress emphasis.

This might look like a subtle distinction, but that’s where all of this confusion comes from. The HTML 2, 3 and 4 specs were pretty vague on their definition of “emphasis”, making it look like a lesser version of <strong>. Something to mark text of higher importance, but not so important.

But when HTML5 rolled out, they made sure to draw a clearer line on what they intended <em> to be, while redefining the <i> from a text-italicising tag into a semantic tag that pretty much wraps most other use cases for italics.

But what is stress emphasis? Stress emphasis is the phonetic resource of changing pitch and/or dragging the word to denote a special meaning to it. It marks a word in a way that changes the meaning of the whole sentence. It’s used for a correction, clarification, sarcasm, the key part of a counter-argument, etc.

We made a custom demo for .
No really. Click here to check it out.

Click here to see the full demo with network requests

Native English speakers do this without even thinking about it, but more often than not, those of us for whom English is a second language had to sit through really boring lessons about it.

A quick look at the examples from the spec itself should make it clearer: they take the phrase “Cats are cute animals” and change the <em> tag from word to word, thus changing the meaning from implying that the discussion was about which animals are cute, to imply that the truth of the whole sentence was in question, implying that someone else said they were ugly, to the ridiculous notion that someone confused cats for plants. Or gods. Probably gods.

Some use cases

We can use stress emphasis to communicate the higher importance of a word:

<p>"I'm not <em>that</em> into text semantics"</p>

The emphasis on “that” makes it clear that, while interested in it, it will not stop the speaker from using incorrect tags every now and then.

But we can use it to indicate sarcasm as well:

<p>Sure, another TV is <em>exactly</em> what our family needs</p>

To correct or clarify information, quoting Quackit excellent guide on text-level semantics:

<p>"Did you say that you are a <em>chameleon</em>?"</p>
<p>"No, I am a <em>comedian</em>"</p>

We might also use it to hint at some implications:

<p>What <em>we</em> need to do is finish this project asap</p>

The emphasis implies that there’s someone else who needs to do something else.

It’s also used to mark the point of confrontation:

<p><em>Dogs</em> are cute animals</p>

I’m implying a confrontation with somebody else who claimed other animals are cute (in this case, whoever wrote the HTML5 spec example) and marking the point of discrepancy.

<em> tags would normally be used on single words, maybe two, but we can sometimes use it on the whole sentence, to mark that the speaker is really fighting to get their point across, or denote an urgency. An exclamation can be the right use for <em> in a phrase:

<p><em>We need to get out of here!</em></p>

Our tools are broken

There are a gazillion WYSIWYG editors that get this wrong. From actual software intended to ease the creation of simple websites by drag-and-drop to blogging platforms; If your editor has the typical “italics — bold — underline” buttons, then most likely there’s nothing semantic about it.

Most (possibly all) of the ones that claim to be “semantic” are just throwing <em> for any italicised text and <strong> for bold text, without giving a thought about why the text is formatted that way (which is exactly what “semantics” try to solve). If there are no independent buttons for <i> and <em>, or a super-intelligent algorithm capable of interpreting why you are italicising text and applying the correct tag for the use case, it’s not semantic.

Even our modern tools fall short when it comes to this. Markdown implementations use exactly the same approach of <em> for italicised text, <strong> for bold text.

Some of the reference guides on it even go as far as saying

Emphasis, aka italics, with asterisks or underscores.

Which, at that point, really makes me think it might be the developers and not the tools.

I get it, Markdown is intended for quick writing, it even says so in the documentation

Markdown is not a replacement for HTML, or even close to it. Its syntax is very small, corresponding only to a very small subset of HTML tags. The idea is not to create a syntax that makes it easier to insert HTML tags. (…) HTML is a publishing format; Markdown is a writing format. Thus, Markdown’s formatting syntax only addresses issues that can be conveyed in plain text.

We could (in some implementations) manually use the <i> tag inside markdown formatted text, but even then, I feel like they should have addressed both in the language.

When NOT to use <em>

There are many cases where italics are meant to represent something other than emphasis.

In which case, the correct tag is actually <i>. Some may think <i> is a non-semantic tag, but it’s actually pretty much a catch-all tag for use cases where we want italicised text without stress emphasis.

To quote from the spec

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

For instance, we should use <i> when marking an idiomatic phrase from another language, with their corresponding lang attribute so screen readers get the right pronunciation:

<p>I would like us all to use better text-level semantics, but <i lang="fr">c'est la vie</i></p>
<p>Major of Springfield, <i lang="la">Corruptus in Extremis</i></p>

It is also used for taxonomic nomenclature:

<p><i lang="la">Carnivorous Vulgaris</i> keeps chasing his prey, <i lang="la">Accelerati Incrediblus</i> </p>

To mark a technical term:

<p>Concepts like <i>closure</i> can be confusing to JavaScript beginners</p>

fictional character voices:

<p><i>- That's what I do: I drink and I know things</i></p>

thoughts:

<p><i>I am better than this</i>, she thought as she walked away</p>

and some other use cases, depending on the language (such as ship names).

Another italic-causing tag that we might find a good use for is the <cite> element.

It is used to mark the title of a work (painting, book, etc):

<p><cite>The persistence of memory</cite> by Salvador Dalí. Painted in 1931</p>

or the author:

<p> According to <cite title="You're using <em> wrong. Published by LogRocket (October, 2018)">Facundo Corradini</cite>, we should reconsider the tags we're using to italicise text.

In many platforms <blockquote> causes the text to be italicised (as well as indented), but I don’t think anyone is confusing that one with <em>, and editors always have the proper button for it. It can cause some nesting issues though, so that’s something to keep in mind.

Why it matters

Accessibility, of course. Every time we use the wrong tag to italicise a word, most of our users won’t even notice. As long as we are doing so according to our language conventions, the word will be read with the intended emphasis.

But we are making things so much more complicated for screen readers, especially when nesting. If we were doing our job right, speech synthesizers would be able to easily make the right pitch corrections. But we’re so far gone in this that all of them (as far as I know) have it disabled by default, and that’s a big part of what makes them feel so unnatural.

It can be enabled in some, but even then, they opted to just get anything that’s italicised and apply the inflection.. which is just as bad. They are correcting our errors.

But maybe, if we all start doing it the right way, we can get them to work properly in the future and feel much more human. We can communicate better.

Nested “italics” tags

I have to admit, this whole article kind of started with my strong disagreement with this CSS-Tricks tweet on “nested emphasis”:

No Title

Nested emphasis? Undo it.“`em em { font-style: normal;}“` pic.twitter.com/YIaBPoKvod

Let’s break that down:

<em>Now <em>that's</em> a change, she thought</em>
em em { font-style: normal;}

Now that’s a change, she thought

The given phrase is a fictional character’s thought, who is putting emphasis on “that’s”, implying the change they’re talking about is really noticeable, probably compared to another, previous small change.

For starters, “Now that’s a change” is a thought, so it should be marked down with an <i> tag, not <em>. But as we previously discussed, pretty much all of our tools are forcing us to do these kinds of things, so I can live with that.

The part that really bugged me was the core idea of resetting the italics. To me, it looks like the worst possible solution. It doesn’t just fail to convey the intended stress on that word, it actually makes it appear outside the scope of the fictional character’s thought.

Look how much better it conveys the stress if we opt for adding bold weight instead:

<i>Now <em>that's</em> a change</i>, she thought
i em { font-weight: bold;}

Now that’s a change, she thought

Some might argue that an underline would get the job done just as well, which might be true for print, but it’s clearly a no-go for the web, as it would make it look like a link:

<i>Now <em>that's</em> a change</i>, she thought
i em {text-decoration: underline;}

Or maybe use caps, after all, it’s just one word. Personally, I believe this one goes over-the-top and might be better suited for nesting bold-causing tags, as it’s commonly interpreted as shouting:

<i>Now <em>that's</em> a change</i>, she thought
i em {text-transform: uppercase;}

Now THAT’S a change, she thought

There are some other combinations of tags that would cause italicised text inside an italicised scope, but most of them are <em> inside some other tag, so I would argue that just setting the inner tag to bold does the trick almost every time.

Takeaways

• Whenever you’re throwing italics at a word/phrase, think about why are you doing so and choose the right tag for the task if possible
• When in doubt, read it aloud. Or get someone else to read it aloud and see if it matches your expected inflections
• If you’re using italics on more than one or two words, <em> is probably not the right tag
• Marking a whole phrase with <em> means urgency, so it would normally only be used in exclamations
• When nesting italics-producing tags, go for a bold weight. And for the love of HTML, do not undo them!

We need to start considering why we are italicising text and using the right tag for it. We can make our tools better. We can make the web better.

LogRocket: Full visibility into your web apps

LogRocket is a frontend application monitoring solution that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.

In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single-page apps.

Try it for free.