Optional HTML: Everything You Need to Know
Post from August 20, 2019 (↻ October 19, 2022), filed under Web Development (feed).
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.
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.
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
- no single or double quotes (evidently, as we’re talking about the unquoted syntax) or grave accents (“`”),
- no equal signs (“=”),
- no “greater than” (“>”) or “less than” (“<”) signs,
- no ampersands,
- no spaces and line breaks,
- no null characters (U+0000), and
- no end of file,
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.
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:
<p>Example</p> <img src="foo" alt="Bar">
If all optional code is omitted, this turns into
<p>Example <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.
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!
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe this is interesting to you, too:
- Previous: Sources 2019
- More under Web Development, or from 2019
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.