HTML Code

Presenting code blocks in HTML documents has become quite a common activity given that there are countless websites that ought to deal with showcasing code snippets.

Tech blogs, platforms teaching programming (such as this one), software documentations, API providers — there is a whole ton of places where being able to present code to the user is a vital requirement.

And not just code; we also need to showcase the output of the code when trying to replicate terminals windows and CLI applications using HTML.

In this chapter, we shall learn about two HTML elements to help us in this regard: <code> and <samp>. Following this, we'll learn about the <kbd> element, which although isn't precisely tied to code, gets rendered using a monospaced font and thus is explored right alongside these code-related HTML elements.

To showcase computer code in an HTML document, we use the <code> element.

By default, since it represents code, browsers render the text inside a <code> element using a monospaced font.

Let's see what that is.

Let's now consider a quick example of <code>.

In the following code, we lay out a sentence stating a fact about variables in JavaScript, involving two keywords (which represent JavaScript code):

<p>In JavaScript, <code>var</code> and <code>let</code> both define variables.</p>

We mark up these keywords using the <code> element.

Following is the output produced:

Notice the words 'var' and 'let' above — they both are based on a different font than that of their surrounding text.

Keep in mind that <code> itself is NOT meant to display a whole block of code; instead, it's meant for presenting inline code, along with other text.

Likewise, the following isn't really desirable:

<p>Here's some JavaScript code:</p>

<code>var x = 10;
console.log(x ** 2);</code>

In fact, if we take a look at the output produced when using <code> alone, as follows:

we see that new lines in the code text don't get rendered out on the document.

If we wish to denote a whole block of code appropriately, we should encapsulate <code> inside a <pre> element.

This is illustrated below:

<p>Here's some JavaScript code:</p>

<pre><code>var x = 10;
console.log(x ** 2);</code></pre>

Thanks to <pre>, the new lines in the code get rendered correctly out on to the document.

Simple, yet perfect!

Let's say we have some code displayed on an HTML page and now wish to showcase the output text generated by that code. Which element should we use here?

Well, this is the job of <samp>.

The <samp> element stands for 'sample output' and is meant to represent the textual output generated by a computer program.

Akin to <code>, browsers render the text inside a <samp> element using a monospaced font as well, by default. This makes sense because when working with real code, its output is typically presented in terminal programs which also use a monospaced font for rendering.

And again just like <code>, <samp> on its own is used to denote inline output text. If we wish to represent a block of output, we need...you guessed it...a <pre> element.

Time for an example.

Let's say we want to write out a sentence on an HTML document saying that a particular function call in Python produces a given output. Here's how we'd do so:

<p>The <code>print(11 ** 2)</code> function call in Python outputs <samp>121</samp>.</p>

The short code statement of Python is wrapped up inside the <code> element whereas the output produced by it, i.e. 121, is wrapped up inside the <samp> element.

Reiterating on it (because it's such an important point), just like <code>, <samp> on its own should be inlined with other content; it should NOT be used to denote a whole block of output on its own.

So, for instance, the following isn't an ideal usage of <samp>:

<p>The code produces the following output:</p>

<samp>0 1 2
-1</samp>

We have a block of output marked up using <samp> without anything wrapping up the element. Because <samp> isn't originally meant to represent blocks of output, this usage of <samp> isn't considered that good.

Here's the output produced:

We have the same issue we had above when we used the <code> element alone to represent a piece of code containing new lines.

That is, -1 appears on the same line as 0 1 2 despite the fact that it's on a new line in the source code. This happens because <samp> follows the typical whitespace behavior of elements in HTML, i.e. to reduce down a sequence of whitespace characters to a single space.

If we wish to denote a block of output text using <samp>, then we should...you guessed it again...wrap the <samp> element inside a <pre> element.

Likewise, the code above should be rewritten as follows:

<p>The code produces the following output:</p>

<pre><samp>0 1 2
-1</samp></pre>

Here's the output this produces:

0 1 2
-1

So was this easy or not?

Often times, we might want to mark up text that represents keyboard input. For this, we have the <kbd> element.

As a simple example, suppose we have a webpage explaining a program's graphical interface. The program might have some keybindings configured for different actions, like Ctrl and S to save a file.

To denote such keybindings on the webpage, we can use the <kbd> element.

Let's see a quick example:

<p>To save a file, we use <kbd>Ctrl + S</kbd>.</p>

As can be seen here, <kbd> elements also render their content using a monospaced font (which can obviously be changed using CSS).

Sometimes, besides denoting keybindings, <kbd> can also be used to showcase text input using a keyboard.

An example follows:

<p>To list all items in the current directory, enter <kbd>dir</kbd> in the terminal.</p>

Here, 'dir' isn't really any code, nor any sample output, but rather some input that the user has to enter into the terminal, hence we denote it using the <kbd> element in lieu of using <code> and <samp>.