Time for de<pre>cation?

The HTML tag <pre> is convenient for preformatted text, but does it still make sense in a semantic world?

A few weeks back, I suggested this topic on Reddit and got some backlash (in part because of my poor wording.) Later, talking to other developers and web professionals, most agreed on the opposite of what Reddit told me.

The center of the discussion was the <pre> element in HTML, its usefulness and meaning, and to some extent, even if it should (or should not) be deprecated.

This whole premise may sound ludicrous or even ridiculous: “What do you mean deprecate <pre>?” But it is a serious question... and I think a valid one.

This article intends not to ask for’s deprecation but to explore and reason arguments of why it hasn’t been. Similar tags lost that battle. What makes <pre> unique and different compared to them?

The <pre> element

This is the definition of <pre> in the HTML Standard:

The pre element represents a block of preformatted text, in which structure is represented by typographic conventions rather than by elements.

This means that the pre element is a block of text that needs to be presented as written (e.g., keeping the original spacing) instead of displaying it as if it was “regular text.”

The definition provides some examples of when to use the element: when including an email or fragments of code or displaying ASCII art. And it continues…

To represent a block of computer code, the pre element can be used with a code element; to represent a block of output, the pre element can be used with a samp element. Similarly, the kbd element can be used within a pre element to indicate text that the user is to enter.

Finalizing with some actual code examples of <pre> to present computer code, mixed with <samp> and <kbd>, or to output a poem in which spacing may be essential.

The semantics problem

The definition of <pre> in the HTML standard is based on the how and not the what. It tells us about the presentation of the content rather than about the meaning (semantics) of the content.

A preformatted text could be anything: an article, a drawing with text, a whole novel, or some programming code… the semantics are provided by the HTML elements around it. <pre> in itself is devoid of meaning:

• if it appears with <code>, it is code;
• if it appears with <samp> it is a sample or output;
• if it appears with <kbd> it is a keyboard input...

This happens because <pre> is a “meta-element.” It’s an element that can go anywhere with anything and doesn’t really provide value (outside of the styling that CSS could provide.)

<pre> doesn’t provide any more semantic value than what <div> or <span> do to their content. Which is zero. It is basically a <div> with opinionated style:

pre {
    display: block;
    font-family: monospace;
    white-space: pre;
    margin: 1em 0px;
}

This is why I started wondering about’s actual usefulness (especially from a semantics perspective).

Arguments supporting <pre>

More intelligent people than I have worked in the HTML standards, and they haven’t found reasons to consider <pre> for deprecation. I had to be missing those reasons. So I turned to the Internet, looking for answers.

This is a summary of the key reasons for those inquiries:

• <pre> has semantic value
• <pre> doesn’t have a semantic alternative
• <pre> provides key accessibility information
• <pre> is shorter than the CSS alternative
• <pre> is useful for debugging

Now let’s see them in more detail with some commentary.

<pre> has semantic value

This is categorically incorrect based on the text from the HTML standard. Preformatting does not add meaning; it’s not enough to provide semantic value. The preformatted text can be a poem, an image, a mathematical formula, or just plain text… it all depends on the context around it.

Formatting is presentation. Semantics are meaning. A preformatted text is a text with some special presentation, not a meaningful text in itself.

The afterthought that “<pre> doesn’t have a semantic alternative” complemented this argument. For example, some poems play with the spacing. If the poem is in an article, <pre> would be the only option because it respects the spacing.

And we’d go back to the same idea: spacing is presentation. In web development, HTML is responsible for the content and structure, and CSS defines the styles and presentation. Picking an HTML element based on how the browser will display it is wrong. It may look nice in some browsers but causes problems down the road (e.g., skipping headings so the style matches.)

In the poem example above, the right element is an <article>. It is a complete, self-contained composition. And there is nothing wrong with nesting articles!

<pre> doesn’t have a semantic alternative because <pre> doesn’t have semantic value in itself. The semantic alternative would be a <div> (or whatever element <pre> is wrapping) with CSS styles.

<pre> provides key accessibility information

In particular, assistive technologies like screen readers could consider the <pre> spacing to add pauses where needed (e.g., longer breaks if there’s more than one space.)

And this would be an important factor… if it wasn’t for two things:

1. At the moment, no screen reader interprets <pre> differently. It is read how any paragraph or <div> is read. There’s nothing special about it.
2. Screen readers consider CSS when reading elements: display, opacity, visibility, etc. The screen readers could read white-space: pre differently, too.

If screen readers supported <pre>, then we could say using it had accessibility advantages. But they don’t. And if they did, they could support the CSS option too. Making this a moot argument.

<pre> is shorter than the CSS alternative

This is generally true. It is based on the idea of doing something like this:

.pre {
  font-family: monospace;
  white-space: pre;
}
<article class="pre">
  ...
</article>

Requires more typing/coding/transferring of data over the network than doing this instead:

<pre>
  <article>
    ...
  </article>
</pre>

This is true in that particular case, but it is also relative to how the CSS is defined and how many times a <pre> section is loaded. The <pre>-approach is shorter if that type of section doesn’t show up much, but if many are present (no pun intended), the CSS-approach will save bytes. And in any case, it would be a negligible amount.

There is a term for this: premature optimization. And there’s a reason why they say it’s the root of all evil in programming.

<pre> is useful for debugging

Initially, I thought this was a joke, but people were serious: to debug server-side languages faster, they output variables and display them in HTML using <pre>.

For example, in PHP, they would use <pre> to show a var_dump() of an object or array because it will make the output easier to read as it respects the original spaces.

There are many reasons why this is not a valid reason to keep an HTML element as part of the standard:

1. <pre> is not the best semantic element for the job: <samp> or <output> would be more fit.
2. We can style any element to respect white spaces (if that’s what we need).
3. The lack of debugging features in a language should not condition another language.

The third point is critical: if PHP doesn’t have an easy way to debug (or the developer doesn’t know about any), that should not affect what can be done in HTML. PHP is PHP, and HTML is HTML. The deficiencies of one language or technology should not affect a different and independent language or technology standard.

There have to be more reasons, but those were the ones presented during our online conversations.

The precedents

HTML is a living language. It grows and changes continuously: new elements are added, other elements are deprecated, properties and values come and go…

Generally, if a tag does not hold semantic value, it becomes obsolete and deprecated. Some examples of this are:

• <center>: used to center its content.
• <big>: to indicate segments with larger font sizes.
• <font>: to define the content’s font face, size, or color.

Other times, the tag is repurposed. That’s the case of <b>: it was initially used to indicate bold text, but now it is used to bring attention to the element.

In this case, <pre> falls precisely in the same category as <center>: it is a tag that says how the content is displayed (preserving spaces/centered) without providing any information about what type of content is inside.

Conclusion

<pre> may be a convenient HTML tag to help format some content, but its usefulness seems limited, as a developer could mimic its styles easily with CSS.

The arguments presented online don’t seem conclusive. But there has to be something else why <pre> survived when similar elements were considered obsolete or deprecated.

From a personal perspective, <pre> does not add any semantic value to the content it wraps, and it should be avoided when possible. Opting for more semantic elements that would be styled via CSS if needed.

They were originally published at https://alvaromontoro.com on April 25, 2021.