1. Use Tables (for Tabular Data)

It’s 2024, but let’s go back to the year 2007.

A different time in web development—more developers built their own websites, expressed support for conformance with web standards, and separated concerns. (They also embraced slow-moving browsers, poor interoperability, and limited tooling.)

But I don’t want to focus on that time; I just want to pick something from there. In 2007, I ran a now-dead series on my website, “Code I Saw Today.” In one of its early editions, it covered a website that featured the following table:

That table, however, had been implemented as follows:

There’s a lot to unpack, which makes this case interesting and worth retrieving. In an order that allows us to look at the more interesting HTML questions last:

• The no-break spaces.
• The use of “o/oo” (for “‰”).
• The capitalization of HTML elements.
• The use of the strong element.
• The use of br elements.
• The lack of a—table.

The no-break spaces represent a way of “layouting” that existed in the late 1990s and early 2000s. Using spaces wasn’t all too common, but it did occur. As you already know, we rarely need no-break spaces, at least not in cases like this.

As for the permille hack, this may have been done in ignorance of using the actual symbol, “‰”, but it may have also been solved like this due to interoperability problems. We weren’t always in the comfortable position of so much widespread support for Unicode and its many glyphs.

The capitalization of HTML elements is a stylistic choice. I appreciate it, and although no one seems to write HTML like this anymore, I believe in the field, we could appreciate it, too. It reflects the original style of writing HTML, as we can tell from specification-like documents like HTML 1’s HTML Tags or HTML 2’s Document Structure. Although no one writes HTML like this today, nothing is speaking against it.

Let’s review the HTML itself.

The strong element is being misused here. The content represents either a heading or a table caption, which we’ll discuss in a moment.

The br elements are likewise being misused, to force table rows. (Line breaks are often an indicator for presentational thinking—though not always, as I explained in Chapter 3 of Upgrade Your HTML III.)

Finally, we’re looking at tabular data, but there’s no markup for a table—in a document from a time in which tables were used for everything.

So what could an optimized version of this look like?

(What you won’t see here are special, invisible characters like U+00A0 no-break spaces before “ha” and after “Fr.” These are useful to keep value and unit together, and therefore to support understanding.)

I made two decisions that could also be made differently:

1. Using a caption instead of a heading: From the context we have, “Zahlen und Statistiken” (“numbers and stats”) could be a page heading or a table caption. Context as well as intent usually provide us with an answer, but as we don’t have that, I opted for a table caption. To me, it looks more appropriate.

2. Not using a tbody element: HTML has three extra elements to structure tables—tbody, thead, and tfoot. These aren’t frequently used, either, something you can confirm in the HTTP Archive’s data for the Web Almanac (e.g., for 2022). In this case, I chose not to use any of these elements explicitly—the table is simple, and with its horizontal flow with table heads on the side, it felt more functional as well as sufficient to work with th elements and the scope attribute. (Why do I say “explicitly”? Depending on the table structure, at least tbody is still present, because it’s implied.)

From a purist perspective one could debate the scope attributes: The table is usable and accessible without them. Other than that, not much more can be omitted, and the resulting code is valid.