See the Forest for the Trees
1 <ul class="nav__menu nav__menu--depth1 sub-menu">2 <li class="nav__menu-item nav__menu-item--depth1 menu-item menu-item-type-post_type menu-item-object-page menu-item-105848"><a href="https://www.whitehouse.gov/about-the-white-house/tours-events/" class="nav__link">White House Tours</a></li>3 <li class="nav__menu-item nav__menu-item--depth1 menu-item menu-item-type-post_type menu-item-object-page menu-item-105855"><a href="https://www.whitehouse.gov/about-the-white-house/presidents/" class="nav__link">Past Presidents</a></li>4 <li class="nav__menu-item nav__menu-item--depth1 menu-item menu-item-type-post_type menu-item-object-page menu-item-105862"><a href="https://www.whitehouse.gov/about-the-white-house/first-ladies/" class="nav__link">Past First Ladies</a></li>5 <li class="nav__menu-item nav__menu-item--depth1 nav__menu-item--has-submenu menu-item menu-item-type-post_type menu-item-object-page menu-item-has-children nav__menu-item--has-menu-5 menu-item-105995"><a href="https://www.whitehouse.gov/about-the-white-house/the-grounds/" class="nav__link">The Grounds</a></li>6 <li class="nav__menu-item nav__menu-item--depth1 nav__menu-item--has-submenu menu-item menu-item-type-post_type menu-item-object-page menu-item-has-children nav__menu-item--has-menu-7 menu-item-106079"><a href="https://www.whitehouse.gov/about-the-white-house/our-government/" class="nav__link">Our Government</a></li>7 </ul>
This example is from the former U.S. administration’s website for the White House. This is a technical book and not a political one, so let’s look at the code. It handles 5 list items which, in turn, handle 12 words. The amount of code, because there’s so much of it, makes it hard to tell what the content is all about. That’s the point we’re starting with:
If your HTML code vastly exceeds the amount of information it contains, it’s a signal there’s a problem (with the code).
In this example, most code comes from the number, length, and repetition of the various class names. Yes, we see BEM here, the CSS methodology we covered a little more in chapter 5 of Upgrade Your HTML II. And yet we also see why the classic ground rule for ID and class names, to make them as long as necessary, but as short as possible still has value. It shows, too, why we hold “Don’t Repeat Yourself” in high regard as an engineering principle: It keeps our code more focused and easier to understand.
What do we do? If you’re new to this book series, I’ll probably seem radical: We throw out everything that doesn’t have an obvious reason for existence.
1 <ul class=nav>2 <li><a href=/about-the-white-house/tours-events/>White House Tours</a>3 <li><a href=/about-the-white-house/presidents/>Past Presidents</a>4 <li><a href=/about-the-white-house/first-ladies/>Past First Ladies</a>5 <li><a href=/about-the-white-house/the-grounds/>The Grounds</a>6 <li><a href=/about-the-white-house/our-government/>Our Government</a>7 </ul>
If you compare this with the original code, you’ll recognize the benefits of leaving out optional code; of not repeating ourselves; of keeping things simple. This is why we do this.
Yet then, question this. What happened here? Why? Are the underlying assumptions fair?
A more obvious change may be the truncating of link targets—all the links have been made relative to the root, stripping “https://www.whitehouse.gov”. There can be cases where using the full URL is useful (like when a page is available on several domains, and you wish to lead users to the canonical one), but there are also alternatives for handling this (as with redirects). For same-site URLs, it’s often more convenient, and less payload, to work with relative links.
A classic change for this book series, but one that not all readers may be familiar with, is the decision to strip all optional markup. You notice the missing quotes as well as the missing closing
</li> tags. They are optional and would only increase page weight.
While it may be a matter of taste whether you want to keep optional code in your code base, at least for production it seems useful to remove it. Personally, I write HTML so that it doesn’t include anything optional (exceptions would prove the rule).
Yet that leaves us with a drastic change: the aggressive consolidation of classes. They are all gone. Was this a reasonable change? To answer this, let’s look at the navigation in question:
White House navigation.
What do you notice? What we’re discussing is actually a subnavigation (so the
nav class looks not entirely wrong, but off), whose styling is fairly straightforward. While we could go on now and discuss CSS naming methodologies and their pros, cons, and alternatives, I’d like to ask you to play with the idea of keeping it simple; or even simpler:
1 <ul>2 <li><a href=/about-the-white-house/tours-events/>White House Tours</a>3 <li><a href=/about-the-white-house/presidents/>Past Presidents</a>4 <li><a href=/about-the-white-house/first-ladies/>Past First Ladies</a>5 <li><a href=/about-the-white-house/the-grounds/>The Grounds</a>6 <li><a href=/about-the-white-house/our-government/>Our Government</a>7 </ul>
Make use of element context, as with descendant combinators. Within the surrounding navigation (which could well use one or more classes), it looks entirely possible to do without any class for this submenu. Possible. Which is where I suggest we leave this chapter.
Don’t Overuse Classes
In the first draft of this book, I had included a different chapter 6: Don’t Overuse Classes. It reminded me so much of this chapter that I thought not to axe it, but to add it to this one. So here’s another view of the use of classes.
1 <div class="relative z-10 col-start-1 row-start-1 px-4 pt-40 pb-3 bg-gradient-to-t from-black sm:bg-none">2 <p class="text-sm font-medium text-white sm:mb-1 sm:text-gray-500">Entire house</p>3 <h2 class="text-xl font-semibold text-white sm:text-2xl sm:leading-7 sm:text-blackmd:text-3xl">Beach House in Collingwood</h2>4 </div>
In this particular case, let’s begin with ambitiously optimized markup:
1 <div>2 <p>Entire house3 <h2>Beach House in Collingwood</h2>4 </div>
(This optimization is ambitious because it seems likely that these are not the only
h2 elements on the page, suggesting some hook, like a class, is still needed to style the markup.)
Now some of you may have recognized where these classes originate from—from Tailwind CSS. Tailwind is an approach to tightly couple structure and presentation based on the idea that both are easy to maintain and change together. (When this is the case, Tailwind seems to work well for developers. If neither structure nor presentation is easy to change, Tailwind is a disaster, because it violates the paradigm of separation of concerns promoted with the first paradigm of frontend development.)
The point is this: Even when the mentioned premises hold—easy maintenance of the markup (perhaps through components) and interlocked changes to both structure and presentation—, this makes for a ton of extra markup (329 bytes vs. 68 bytes).
It is, as always, your call to decide whether such an increase is acceptable, perhaps because you find advantages elsewhere. It is, as always, useful to make this a conscious decision. It’s just that Tailwind comes with a formidable tax on markup size and markup understandability.
Tailwind counts as an HTML/CSS framework, and (developing) frameworks is a topic I love! In 2015 I wrote a small booklet about developing (but also using) them: The Little Book of HTML/CSS Frameworks. I believe it still shares useful thoughts on frameworks. You can access it for free at O’Reilly.
German readers, by the way, can obtain a relatively inexpensive yet also updated edition in German: Das kleine Buch der HTML-/CSS-Frameworks. I consider this a fine book on the matter—but what else am I to say.