—-TOPIC

This is silly question since I already know the answer,
but, in the olden days we used the HTML tag <i>.
Then we stopped using it and used <em> for semantics instead.
Now, 2026, tell me where we stand with those trends.

REPLY

The question isn’t silly at all — it’s one of those “web‑craft” questions where the practice and the philosophy have shifted over the years, and it’s worth checking where things actually stand today.

Here’s the clearest, most up‑to‑date way to think about <i> vs <em> in 2026.

<em> = semantic emphasis

Use it when the meaning of the sentence changes if the word is stressed.

Example:

This is really important.
→ <em>really</em>

Screen readers will announce it with emphasis. Search engines understand it as meaningful. It’s part of the document’s semantics.

<i> = a different voice or category of text

Use it when the text is stylistically different, but not emphasized.

Examples:

• foreign words | technical terms | taxonomic names | ship names | internal thoughts in fiction | editorial notes | titles of works (depending on your style guide)

This is exactly the kind of thing you do in your wikis — small shifts in voice, tone, or category. <i> is perfect for that.

Around the HTML5 era, developers were told:

“Don’t use <i> or <b> — use <em> and <strong> instead.”

That advice was well‑intentioned but oversimplified.

HTML5 actually reintroduced <i> and <b> with clear semantic definitions.
They are no longer “just styling tags.”
They have meaning again — just a different kind of meaning.

The modern, standards‑aligned practice is:

• Use <em> for emphasis.
• Use <i> for alternate voice or category.
• Use CSS for pure styling (no meaning).

This is exactly how browsers, screen readers, and search engines interpret them today.

— TOPIC

The question arose when I decided to emphasize the word wiki in my landing page URL: English wiki (daily writing). I began to think, am I just styling the term wiki as a visual effect or am I also telling the search engines that “wiki” is an important term. And the answer is both.

REPLY

You’re thinking about it exactly the way a modern web‑craftsman should.
When you italicize wiki in that context, you’re doing two things at once, and both are valid in 2026.

Let’s break down what’s actually happening under the hood.

In your landing page list, wiki is a category label — a small shift in voice, not a dramatic stress. Using <i> there is a stylistic cue:

• “this is a type of thing”
• “this word belongs to a category”
• “this is a label, not part of the sentence’s emotional meaning”

That’s exactly what <i> is meant for today.

Search engines don’t treat <i> as “strong emphasis,” but they do treat it as:

• a distinct term
• a meaningful category
• a word with contextual importance

It’s not as strong as <em> or <strong>, but it’s not neutral either.
It tells crawlers:

“This word is being presented in a special voice.”

And because wiki is a relevant keyword for your site, this is a perfectly appropriate signal.

If you had used <em>, you’d be saying:

“This word changes the meaning of the sentence if stressed.”

But that’s not what you want.
You’re not emotionally emphasizing wiki — you’re categorizing it.

So <i> is the correct choice both:

• semantically (alternate voice)
• stylistically (gentle visual cue)

And yes, search engines understand that distinction.

Your landing page is intentionally quiet:

• plain list
• minimal styling
• no marketing tone
• no SEO theatrics

Using <i> for wiki fits that philosophy.
It’s a whisper, not a shout.

You’re not overthinking it.
You’re doing exactly what modern HTML expects:

• <i> for category/voice
• <em> for meaning/emphasis

And in your case, wiki is both a category and a keyword
— so the choice is spot‑on.

—-TOPIC

On this thought, when should we use <b> in modern HTML?

REPLY

In modern HTML, <b> has a very real purpose, but it’s very different from what people used it for in the 1990s.
The key is that <b> is not about emphasis anymore — it’s about stylistic offset without semantic weight.

Think of it this way:

• <em> = meaning changes if stressed
• <strong> = importance or urgency
• <i> = alternate voice or category
• <b> = visual distinction with no semantic meaning

Only when you want something to stand out visually,
but you’re not trying to say it’s important, emphasized, or a different voice.

<small> is one of those tags that quietly survived the early‑web chaos and, like <i> and <b>, was given a clear semantic purpose in HTML5. It’s not just a styling tag anymore.

Here’s the modern understanding.

<small> indicates side comments, fine print, or secondary information — text that is less central to the main narrative.

• It’s not “whispered emphasis.”
• It’s not “make this visually tiny.”
• It’s “this text is context, not core.”

Browsers do render it smaller by default, but the semantic meaning is:

• “This is auxiliary, legalistic, or low‑priority text.”

—-TOPIC

So if my intention is to visually make it smaller but I don't want relevance side effects, is it best to style it in CSS rather than in the HTML markup?

REPLY

Absolutely — that’s the cleanest, most future‑proof approach.

When your intention is purely visual, and you don’t want to imply anything about meaning, importance, or metadata, then CSS is the right tool.
HTML elements like <small> carry semantic weight, even if subtle.

• CSS carries zero semantic meaning.

Here’s the practical rule of thumb:

• If it’s meaning → use HTML.
• If it’s appearance → use CSS.

And in your case, you’re saying:

• “I want this text smaller.”
• “I don’t want search engines or screen readers to treat it as secondary or fine print.”

That’s a perfect moment for CSS.

You can create a tiny utility class:

<span class="small-text">Updated January 2026</span>

And in your CSS:

.small-text {
    font-size: 0.85em;
}

This gives you:

• no semantic side effects
• predictable styling
• full control over size
• consistency across your wikis

Using CSS for purely visual adjustments keeps your HTML meaningful and your design quiet.

See: Example case here

Back to

• MachineTalk Topics
• General Tech Notes
• Home Page