Time for dePREcation?

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 <pre>'s deprecation, but to try to explore and reason arguments of why it hasn't been. Similar tags lost that battle. What makes <pre> special 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 basically 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 is important.

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, but not about the meaning (semantics) of the content.

A pre-formatted text could be anything: an article, a drawing with text, a whole novel, 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 <pre>'s actual usefulness (especially from a semantics perspective).

Arguments supporting <pre>

Smarter people than me 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 from 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 type of 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 in charge of 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 pauses if there's more than one space.)

And this would be a huge 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 a11y 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 end up saving bytes. And in any case, it would be a negligible amount (probably less than 50 bytes difference).

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 really need).
3. The lack of debugging features in a language should not condition another language.

The third point is key: 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 standards.

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

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...

In general, if a tag does not hold any semantic value, it ends up considered obsolete and deprecated. Some examples of this are:

• <center>: used to center its content.
• <big>: to indicate segments with larger font size.
• <font>: that defined the font size, color, and face for the content.

Other times, the tag is repurposed. That's the case of <b>, which originally was used to indicate bold text, but that now it is used to bring attention to the element.

In this case, <pre> falls exactly 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

While <pre> may be an interesting HTML to help format some content, 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 seem to 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.