In HTML parsing a tag like <main-menu/>, is treated as an opening tag, so non‑void elements require an explicit closing tag.

That’s a tokenizer rule, not a ban on "self‑closing custom elements."
The common claim "HTML5 forbids self‑closing tags for Custom Elements" is misleading:

• HTML disallows XML‑style self‑closing for any non‑void element, custom or not.

Lit templates aren’t authored HTML. Lit use JavaScript literal that produces DOM, with features like ${…} expressions, bindings (.prop=, ?attr=, @&ltevent&gt), directives, non‑string values, part markers ... none of which exist in plain HTML.

So judging them by “HTML5 compliance” is the wrong yardstick.

If the shortcut were allowed by the parser, it would have two clear advantages:

• It’s shorter and more readable in dense templates.
• It’s less error‑prone: no chance of a mismatched closing tag, no accidental content inserted between start/end, and smaller diffs when editing.
• It makes lit more approachable for people coming from other frameworks that allow self closing tags.

While the library could, in theory, rewrite to <main-menu></main-menu>, doing so at runtime adds overhead, and doing it at build time would require introducing a compilation phase that Lit doesn’t have.

Conclusion: this isn’t about "HTML5 compliance".

It’s about Lit intentionally avoiding a compilation phase. Lit keeps templates as runtime tagged literals for simplicity, caching, and alignment with the browser’s parser.

As many still really want the shorthand (e.g., <main-menu> rewrites to <main-menu></main-menu>), it could be explored as a build-time transform outside Lit, such as a TypeScript transformer, or Rollup/Vite plugin and not as a core change to Lit itself.

Is there an official lit typescript transformer that we could build upon?