Challenging the Idea of “Optional HTML”

by @markupninja@hachyderm.io on Oct 22, 2025, tagged guest-posts, html, minimalism (share this post, e.g. on Mastodon or on Bluesky)

[Publisher’s note: Given that Jens’s work is referred to here while he’s also running Frontend Dogma, we accepted the challenge (and asked only for the lightest edits).]

In web development, some topics spark debate—like the practice of omitting “optional” HTML tags. The HTML specification permits developers to leave out certain tags—closing </p> tags, </li> tags, even opening <html>, <head>, and <body> tags—under specific conditions. While this might seem like a shortcut, or even a mark of understanding, the practice deserves scrutiny.

Web developers like Jens [Oliver] Meiert have advocated for minimal HTML, arguing that omitting optional tags leads to cleaner, more maintainable code. Meiert, who promoted the practice in the Google HTML/CSS style guide (“omit optional tags”) and in articles on meiert.com (“leave out optional tags and quotes”), makes a case for understanding and utilizing the HTML specification’s flexibility. Although a niche position, sometimes others in the web standards community echo similar positions, emphasizing that these aspects of the specification exist to be used.

The Case for Optional Tag Omission

The position rests on several arguments. First, the HTML specification explicitly allows these omissions, making them valid by definition. Why write code the specification doesn’t require? Second, omitting optional tags can reduce file size—admittedly by small margins, but in aggregate, across millions of pages, these savings become meaningful. Third, understanding which tags are truly required demonstrates knowledge of HTML’s structure and parsing rules.

Proponents emphasize that professional web developers should understand the specification. Knowing that a <p> tag automatically closes when another block-level element begins, or that an <li> closes when the next <li> starts, reflects expertise rather than sloppy coding. This knowledge, they argue, separates developers who follow conventions from those who understand the language.

The Practical Counterarguments

Despite the technical validity of this position, several practical concerns make optional tag omission problematic in real-world development environments.

Readability and Mental Load

Code is read far more often than it is written. When developers encounter HTML without closing tags, they must mentally track where elements end based on parsing rules rather than explicit markers. Consider this example:

<ol>
  <li>First item
  <li>Second item
  <li>Third item
</ol>

While valid, this structure requires readers to know the implicit closing rules. Contrast this with:

<ol>
  <li>First item</li>
  <li>Second item</li>
  <li>Third item</li>
</ol>

The second version communicates structure immediately, without requiring knowledge of specification details. In code reviews, debugging sessions, or when onboarding new team members, this clarity becomes valuable.

Tooling and Consistency

Modern web development relies on tooling—linters, formatters, validators, and build systems. Many of these tools expect or enforce explicit closing tags. Prettier, for instance, will add closing tags back. ESLint rules for JSX (React’s HTML-like syntax) require closing tags. When optional tag omission conflicts with tooling standards, it creates friction rather than efficiency.

Furthermore, most development teams work with multiple technologies: HTML, JSX, templating languages like Handlebars or Jinja, and frameworks. Each has different rules about tag closure. Maintaining different mental models for each context increases cognitive load. A consistent approach—always closing tags—eliminates this context-switching cost.

The Collaboration Factor

Arguments for optional tag omission often assume a level of HTML expertise that not all web developers possess. Many developers come to web development through JavaScript frameworks, spending more time with React or Vue than with raw HTML. Others focus on backend development or design. In collaborative environments, code needs to be accessible to team members with varying levels of HTML specification knowledge.

Writing code that requires deep specification knowledge to read creates a barrier. It privileges individual understanding over team comprehension. The file size savings rarely justify this trade-off.

When Specification Knowledge Matters

Understanding optional tags is valuable. Knowing the specification makes one a better developer. This knowledge proves useful when:

Debugging parsing issues: Understanding how browsers implicitly close tags helps diagnose layout problems.
Analyzing legacy code: Older codebases might omit optional tags, and understanding why they still work is necessary.
Optimizing at scale: For organizations serving billions of pages, even tiny optimizations matter.
Working with generated HTML: Server-side or build-time HTML generation might strategically omit tags.

The distinction is between understanding optional tags and routinely omitting them in hand-written code.

A Middle Path

Rather than dismissing specification flexibility or blindly following convention, developers can take a balanced approach:

Learn the specification thoroughly: Understand which tags are optional and why. Read the HTML Standard. If you need it, consider niche optimizations by authors like Meiert later.
Write explicit code by default: In hand-written HTML and templates, include all tags for clarity.
Let tools optimize: Use build tools or minifiers to remove optional tags in production if file size matters.
Document exceptions: If you do omit optional tags, document why in your style guide.

This approach captures the benefits of both positions: Developers understand the language deeply but write code optimized for human readers first.

Conclusion

Work on optional HTML tags represents advocacy for specification literacy. These arguments push developers to understand HTML more deeply rather than following conventions without question. This is valuable.

However, in practical web development—with its emphasis on team collaboration, tooling ecosystems, and code maintainability—the case for routinely omitting optional tags weakens. The file size savings are negligible in an era of compression and caching. The cognitive load on readers, conversely, is real and measurable.

The goal shouldn’t be to write the most minimal HTML the specification allows, but rather to write the clearest code that serves both machines and humans. Sometimes that means embracing verbosity. And that’s acceptable.

Understanding optional tags may or may not make you a better developer. But choosing to write explicit, readable code makes you a better colleague. Both forms of expertise matter, and they need not conflict.

(Frontend Dogma accepts guest posts as long as they aren’t predominantly AI-generated or promotional. Although guest posts are being reviewed, Frontend Dogma cannot and does not vouch for their accuracy, and does not necessarily endorse recommendations made in them.)