Optional HTML: Everything You Need to Know

Published on August 20, 2019 (↻ April 20, 2024), filed under (RSS feed for all categories).

Reasons to keep optional code around typically boil down to understandability, whereas reasons to leave out optional code converge on performance. The two don’t need to be at odds with each other when optional code is worked with in our editors and kept in our repositories but pruned for production.

What code—here: what HTML code—is optional, however? This article gives an overview over everything * optional other than extraneous whitespace and anything standard minifiers already handle. There’s much to omit and omitting is good for us.


  1. Optional Tags
  2. Optional Quotes
  3. Attribute Value Defaults
  4. Appendix I: Risks
  5. Appendix II: Tooling

Optional Tags

The following lists all optional tags (not elements here, let alone attributes) as per current living HTML. End tags of void elements are just there for the sake of completeness, put in parentheses. To understand conditions and requirements it can be useful to read respective spec parts.

Optional Quotes

Attribute values don’t always need to be quoted (no matter single or double quotes). The HTML specification explains in great detail how attribute parsing works, so this section tries to outline when quotes can be omitted, and when not.

<!-- Quoted -->
<link rel="stylesheet" href="default.css">

<!-- Unquoted -->
<link rel=stylesheet href=default.css>

Per the spec, as long as after the equal sign or as part of the attribute value there are

there is no need to quote the attribute value.

Usually, a space would then end the sequence to likely lead to the next attribute, or a “greater than” would indicate the start tag to be complete.

Is there a simpler way than memorizing all those characters? From my experience often omitting optional code by hand (while, important here, employing correct punctuation), yes. The rule of thumb that I use is that when an attribute value doesn’t contain any equal signs or spaces, it’s okay to skip the quotes.

Attribute Value Defaults

We can also save HTML by skipping attributes whose values correspond with their defaults. The following is a list of some attributes that have a default value, which in most cases refers to the missing-value default.

Important: Boolean attributes are not listed; they are basically “on” when present, and “off” when missing. Yet, the spec is a bit hard to extract for attributes—please let me know if you spot any issues or other candidates to be included.

❧ These are the three pillars that optional HTML code rests on. By removing optional tags, not quoting attribute values that don’t need quoting, and avoiding attribute-value pairs that are default we can reduce HTML load to a considerable degree.

The exact extent of the savings varies as much as our preferences to regard this as part of our craft or as part of our tooling. Yet no matter how much is saved precisely, and no matter whether the knowledge is in our heads or in our environment, optional HTML is optional HTML. The tautology suggests that it’s important to know what is “optional,” and what to do with it. This overview is there to assist with that.

King Arthur is wroth. He had not forbidden mortal combat, but he had made it clear that war is imminent and he does not want his knights killed in play.

Figure: Optional honor. (Copyright King Features Syndicate, Inc., distr. Bulls.)

Appendix I: Risks

With a decade of experience (not) working with optional HTML code, and omitting it both manually and automatically, there’s little to add in this section. The reason for this is not that there would be no risks of something “breaking,” temporarily, but a routine: validation.

To this day, HTML (and CSS) validation is a much-neglected practice whose being neglected not only contributes to bloat and bugs, but that also undermines our profession. Those of us who validate rule out basic syntax issues and with that assure a certain base quality, and they usually learn from and get better from respective mistakes. Those who do not validate are very likely to ship inferior code, and they may learn and understand a little less.

Now, while validation helps with correctly omitting what’s indeed optional, there are some perfectly valid edge cases that can be surprising. The most prominent one, and probably the only one you and I may ever really run into, is markup of the following form:

<img src="foo" alt="Bar">

If all optional code is omitted, this turns into

<img src=foo alt=Bar>

…which is, you may notice, something different, for the image, that before spawned an anonymous block element, is now part of the paragraph. [Technically speaking this isn’t actually a place where </p> should be dropped—thanks for the note, Joel Canfield—, but tools may still do it, and it’s valid either way.]

There is no drama here, however. The solution usually consists in keeping respective paragraph closed, or wrapping the image in a non-anonymous element, or, if semantically appropriate, tweaking the markup.

There are no actual risks, and rather many advantages, omitting optional HTML.

Appendix II: Tooling

As the article intentionally leaves it open whether to learn what’s optional in HTML or to abstract it away, tooling has not been a concern here. Still, though currently short, this section will serve to collect significant tools to assist with discarding optional HTML.

HTMLMinifier can handle all of the omissions described, and with the config I’ve introduced at sum.cumo and described in HTML Optimization: A Standard Config for HTMLMinifier, there’s a solid ruleset for HTML production optimization.

For other tools, Andrey Taritsyn has suggested that HTML Compressor, NUglify, and WebMarkupMin are also up to (most of) the tasks, too.

Do you disagree or find that something else should be listed here, too? Please send me a message so that I can clarify and adjust.

* “Everything” as in “everything as far as I can tell, and as I desire it to for this article.” If I missed something I appreciate a note, allowing us to improve the documentation together. Thanks!

Was this useful or interesting? Share (toot) this post, or maybe treat me to a coffee. Thanks!

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma.

With my current move to Spain, I’m open to a new remote frontend leadership position. Feel free to review and refer my CV or LinkedIn profile.

I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.