I used to have this boss who loved, loved, loved, loved to emphasize words. This was way back before we used a WYSIWYG editors and I’d have to handcode that crap.
<p> I used to have this boss who <em>loved</em>, <strong>loved</strong>, <strong><em>loved</em></strong>, <strong><em><u>loved</u></em></strong> to emphasize words.
</p>(Let’s not go into the colors he used for even MOAR emphasis.)
Writing all that markup never felt great. The effort it took, sure, whatever. But is it even a good idea to add overload content with double — or more! — emphases?
Table of Contents
For starters, the <strong> and <em> tags are designed for different uses. We got them back in HTML5, where:
So, <strong> gives the content more weight in the sense it suggests that the content in it is important or urgent. Think of a warning:
Warning: The following content has been flagged for being awesome.
It might be tempting to reach for <em> to do the same thing. Italicized text can be attention-grabbing after all. But it’s really meant as a hint to use more emphasis when readingt the content in it. For example, here are two versions of the same sentence with the emphasis in different locations:
<p>I ate the <em>entire</em> plate of burritos.</p>
<p>I ate the entire <em>plate</em> of burritos.</p>Both examples stress emphasis, but on different words. And they would sound different if you were to read them out loud. That makes <em> a great way to express tone in your writing. It changes the meaning of the sentence in a way that <strong> does not.
Visual emphasis vs. semantic emphasis
Those are two things you gotta weigh when emphasizing content. Like, there are plenty of instances where you may need to italicize content without affecting the meaning of the sentence. But those can be handled with other tags that render italics:
<i>: This is the classic one! Before HTML5, this was used to stress emphasis with italics all over the place. Now, it’s purely used to italicize content visually without changing the semantic meaning.<cite>: Indicating the source of a fact or figure. (“Source: CSS-Tricks“)<address>: Used to mark up contact information, not only physical addresses, but things like email addresses and phone numbers too. (
[email protected])
It’s going to he the same thing with <strong>. Rather than using it for styling text you want to look heavier, it’s a better idea to use the classic <b> tag for boldfacing to avoid giving extra signficance to content that doesn’t need it. And remember, some elements like headings are already rendered in bold, thanks to the browser’s default styles. There’s no need to add even more strong emphasis.
Using italics in emphasized content (and vice versa)
There are legitimate cases where you may need to italicize part of a line that’s already emphasized. Or maybe add emphasis to a bit of text that’s already italicized.
A blockquote might be a good example. I’ve seen plenty of times where they are italicized for style, even though default browser styles don’t do it:
blockquote { font-style: italic;
}What if we need to mention a movie title in that blockquote? That should be italicized. There’s no stress emphasis needed, so an <i> tag will do. But it’s still weird to italicize something when it’s already rendered that way:
<blockquote> This movie’s opening weekend performance offers some insight in to its box office momentum as it fights to justify its enormous budget. In its first weekend, <i>Avatar: The Way of Water</i> made $134 million in North America alone and $435 million globally.
</blockquote>In a situation where we’re italicizing something within italicized content like this, we’re supposed to remove the italics from the nested element… <i> in this case.
blockquote i { font-style: normal;
}Container style queries will be super useful to nab all these instances if we get them:
blockquote { container-name: quote; font-style: italic;
} @container quote (font-style: italic) { em, i, cite, address { font-style: normal; }
}This little snippet evaluates the blockquote to see if it’s font-style is set to italic. If it is, then it’ll make sure the <em>, <i>, <cite>, and <address> elements are rendered as normal text, while retaining the semantic meaning if there is one.
But back to emphasis within emphasis
I wouldn’t nest <strong> inside <em> like this:
<p>I ate the <em><strong>entire</strong></em> plate of burritos.</p>…or nest <em> inside <strong> instead:
<p>I ate the <em><strong>entire</strong></em> plate of burritos.</p>The rendering is fine! And it doesn’t matter what order they’re in… at least in modern browsers. Jennifer Kyrnin mentions that some browsers only render the tag nearest to the text, but I didn’t bump into that anywhere in my limited tests. But something to watch for!
The reason I wouldn’t nest one form of emphasis in another is because it simply isn’t needed. There is no grammar rule that calls for it. Like exclamation points, one form of emphasis is enough, and you ought to use the one that matches what you’re after whether it’s visual, weight, or announced emphasis.
And even though some screen readers are capable of announcing emphasized content, they won’t read the markup with any additional importance or emphasis. So, no additional accessibility perks either, as far as I can tell.
But I really want all the emphasis!
If you’re in the position where your boss is like mine and wants ALL the emphasis, I’d reach for the right HTML tag for the type of emphasis, then apply the rest of the styles with a mix of tags that don’t affect semantics with CSS to help account for anything browser styles won’t handle.
<style> /* If `em` contains `b` or `u` tags */ em:has(b, u) { color: #f8a100; }
</style> <p> I used to have this boss who <em>loved</em>, <strong>loved</strong>, <strong><em>loved</em></strong>, <strong><em><u>loved</u></em></strong> to emphasize words.
</p>I might even do it with the <strong> tag too as a defensive measure:
/* If `em` contains `b` or `u` tags */
em:has(b, u),
/* If `strong` contains `em` or `u` tags */
strong:has(i, u) { color: #f8a100;
}As long as we’re playing defense, we can identify errors where emphases are nested within emphases by highlighting them in red or something:
/* Highlight semantic emphases within semantic emphases */
em:has(strong),
strong:has(em) { background: hsl(0deg 50% 50% / .25); border: 1px dashed hsl(0deg 50% 50% / .25);
}Then I’d probably use that snippet from the last section that removes the default italic styling from an element when it is nested in another italiczed element.
Anything else?
Mayyyyybe:
