...

 preserves whitespace (including newlines and indentation). The combo 
 is the standard pattern for code blocks.
Two practical tips that save pain:
1) Don’t put “code block styling” on 
 alone; style the  inside too, because not all blocks are code.

2) Watch mobile overflow. A 200-character line will break your layout unless you allow horizontal scroll.
Example:
curl -H "Authorization: Bearer $TOKEN" \
https://api.example.com/v1/profile


: user input (keyboard or device)
 is great for instructions:

“Press Ctrl + K.”
“Type yes to confirm.”

Example:

Open the command palette with Ctrl + K, then search for Format Document.


This is one of those tags that improves comprehension immediately.
: sample output
 is for program output (terminal output, logs, responses). This helps separate “what you type” from “what you see.”
Example:

You should see Server listening on :8080 in the logs.


: variables in math or programming explanations
 is underused. I like it for documentation that mixes math and code.
Example:

Let n be the number of retries. The delay is 2n seconds.


A “real-world” snippet combining them
This is the kind of block I’ll include in docs:

Press Ctrl + C to stop the server. If shutdown succeeds, you’ll see bye.

node server.js
output:
Server listening on http://localhost:3000


It reads cleanly because each piece declares what it is.
Quotes and attribution: , 

, and 
Text formatting isn’t only bold/italic. It also includes “voice”: quotes, excerpts, and titles.
: inline quotations
I use  for short, inline quotes inside a sentence.

The error message said Invalid signature, which usually means the token expired.


Browsers often add quotation marks automatically, which is why  is nice: you don’t have to type smart quotes and you avoid inconsistent punctuation.

: longer quotations

 is for longer content that stands apart.


If you can’t explain a system without showing the UI, the semantics are probably missing.



A practical habit: I prefer putting the quoted text in real block elements like 

 inside the blockquote. That keeps spacing consistent and improves styling control.
: title of a work, not “the person I’m quoting”
This is subtle:  represents the title of a work (book, article, film, etc.). People often wrap the speaker’s name in , but that’s not what the element is for.
A more correct pattern is:


Make the meaning machine-readable, then make it beautiful.




I’m not being pedantic here. These distinctions matter when content is repurposed: print styles, exports, summaries, and search all behave better with accurate markup.
Abbreviations and definitions:  and 
These two elements add clarity without cluttering the page.
: abbreviations and acronyms
 is for abbreviations like “CSS” or “TTL.” The title attribute can provide the expansion.

We set a TTL of 24 hours for session tokens.


Two practical notes:

I don’t put title on everything. It can be noisy. I use it when I think the audience may not know the term.
If you’re building a design system, consider styling  with a subtle dotted underline and a tooltip behavior that works on touch devices (because native title isn’t great on mobile).

: defining a term
When you introduce a term with a specific meaning,  makes it explicit.

A nonce is a value used once to prevent replay attacks.


This is especially useful in glossaries or documentation sites where you might later auto-link definitions.
Dates and times:  is formatting with meaning
Dates look like plain text, but they’re a classic example of “formatting vs meaning.” People will write “Feb 3” and move on. Then they build sorting, filtering, and localization, and regret everything.
 lets you display whatever looks best while preserving a machine-readable datetime value.

Last updated Feb 3, 2026.


Why I like this:

Search and indexing can interpret it more reliably
Your future self can parse it without regex
You can swap display formats per locale without changing meaning

If you ever show time ranges,  becomes even more valuable:

Maintenance window: 02:00 UTC–02:30 UTC.


Line breaks, wrapping, and whitespace: 
, , and the “don’t fight text” rule
Whitespace is part of formatting, and it’s also where I see developers accidentally turn HTML into a layout engine.

: line breaks (use sparingly)

 is a line break, not a paragraph. I use it for:

Addresses
Poetry/lyrics (careful with copyright if you’re publishing)
Very compact UI copy where the break is part of the presentation

Example (address):

123 Example St

Suite 400

Springfield, USA


I do not use 
 to “add spacing.” Spacing is CSS. Separate ideas are separate paragraphs.
: word break opportunity
When you have long tokens (URLs, IDs, long file names), you can give the browser safe “break points” with .
Example:

Error ID: 8f3d2c9a-1b24-4a19-8a11-e7a5c3e0b9fa


This prevents mobile layouts from exploding without forcing weird hyphenation.
Soft hyphen ­ (a cautious tool)
Soft hyphens can help with very long words, but I treat them as a last resort because they can create copy/paste quirks. If I need consistent wrapping in product UI, I usually prefer CSS strategies (like overflow-wrap:anywhere) or inserting  in known-safe places.
“Other” formatting tags you’ll encounter: , , and 

Not every formatting tag is part of the “big 10,” but you’ll see these in real codebases.
: underline (with meaning, not just decoration)

 represents “unarticulated annotation” in HTML (think misspellings or proper-name annotations), but most people use it as “make it underlined.”

I avoid  for general underlining because users associate underlines with links. If you want underlined text for style, I prefer CSS on a .

: no longer accurate or relevant

 is for content that’s no longer correct (not “deleted,” just “outdated”).

Example:

Status: Available Sold out


Compared to , which is more explicitly “removed from the document,”  is a lighter semantic signal: “this statement is no longer true.”

: the honest fallback
 is your safe, neutral wrapper. I use it when:

I need a styling hook
There is no semantic element that matches
The text is inline (and a 
 would be incorrect)

But I also impose a constraint: if I’m sprinkling  everywhere, I ask myself whether I’m missing a better structure (like a list, a definition list, a table, or an actual component).
Practical scenarios: what I use in real UI copy
Here are a few patterns I ship regularly.
Inline field requirements
If you’re marking something as required, that’s importance. I prefer  or a structural pattern (like “Required” in the label).

Email (required)


If your design system visually uses an asterisk, remember: the asterisk is not meaning. It’s a symbol. The meaning should exist in text.
Error messages
Errors are not “bold text.” They’re messages that should be discoverable.

Error: The code has expired. Request a new code.


Even if you style .error strong to look subtle, the semantic clue remains.
Search results
I like  for active query matches.

Searching for "cache": clear your cache and refresh.


But I only highlight the minimal match. Highlighting entire paragraphs turns into visual noise fast.
“Fine print” without punishing readability
This is where  shines, but I keep it within reasonable size/contrast.


Free trial available.
Trials convert to paid plans unless canceled before the end date.


If you need the fine print to be legally prominent, don’t shrink it. Use normal size and different layout instead.
Common pitfalls (and what I do instead)
I’ve made most of these mistakes myself. Here’s how I avoid repeating them.
Pitfall: Using  for everything “important”

What breaks: screen readers treat it as normal text; “important” stops being detectable.
What I do instead: use  for importance,  for stylistic labels.

Pitfall: Using italics to mean “required”
What breaks: italics is not meaning; it can also harm readability for some users.
What I do instead: use explicit words like “required” and semantic structure.
Pitfall: Over-nesting  and 

What breaks: text becomes hard to read and styling becomes unpredictable.
What I do instead: if I need multiple visual layers, I usually keep semantics minimal and add a class.
Pitfall: Formatting to fake a list
What breaks: screen readers don’t announce item counts; keyboard navigation tools lose structure.
What I do instead: use 

/

 and style the bullets/numbers.

Pitfall: Using 
 as layout
What breaks: inconsistent spacing; impossible to adapt to different screen sizes.
What I do instead: use paragraphs, lists, and CSS margin.
Performance and maintainability considerations (yes, even for formatting)
Text formatting itself isn’t usually a performance bottleneck, but patterns around it can be.
Keep the DOM honest
A paragraph with a dozen nested spans is harder to maintain than a paragraph with two semantic tags.

Prefer semantic tags when they match meaning.
Use a single wrapper with a class instead of multiple wrappers.

Avoid formatting as a substitute for components
If you have repeating patterns like “Warning:” blocks, don’t hand-format them each time with  +  + random spans. Make a component pattern (even if it’s just a documented HTML snippet) so the semantics stay consistent.

Choose patterns that survive redesigns
A redesign can change font weights and colors overnight. If your “importance” is encoded as , it will survive. If your “importance” is encoded as , it might not.

I’ve seen the best long-term results when teams:

Keep semantics in HTML
Keep presentation in CSS
Use a lint/check step to prevent regressions

A quick checklist I use before shipping text-heavy UI
I do this mental pass any time I’m reviewing a page with lots of copy.

Is anything pretending to be a heading or a button? If yes, replace it with a structural element.
Are warnings and required actions marked with  (or an equivalent semantic pattern)?

Is emphasis () used only where stress changes meaning?

Are / used only for stylistic offsets, not importance?

Are “edits” represented as edits (, , maybe ), not as random red/green spans?

Are code tokens in , and blocks in 
?

Are long tokens wrapped safely ( or CSS) so mobile doesn’t break?

Closing thought: treat formatting tags as part of your content model
I don’t think of text formatting as “tiny tags you memorize.” I think of it as part of the content model of your product. When you make semantics explicit, you make your product easier to read, easier to audit, easier to translate, and easier to evolve.
And that takes you right back to the story at the start: a bold warning that looks correct isn’t enough. The document has to be correct, too.


	
You maybe like,