Provide more context around the permissibility of the XHTML slash on void elements

[hsivonen]

(Not using the template, as this PR is an informative editorial change.)

With issue #9491, the very minor-appearing 2006 concession of the spec not treating /> on void elements as an error, which one would expect to remove the issue from spec debate, comes back to spec debate as a request that would (if accepted) disrupt HTML parsing in an exceptionally significant way.

While we could close an issue like #9491 as rejected without changing the spec text in any way, I think the spec should make more of an effort to dissuade (short of suggesting that conformance checkers complain about it) the kind of perpetuation of the /> syntax (not on @jakearchibald 's part but on the part of people whose comments he is synthesizing into a request) that can escalate to a disruptive-if-accepted spec change request.

The /> syntax was permitted "to make it easier for authors to migrate from XHTML". (See also the longer decision email. We could at least have non-normative language to document the XHTML-related rationale and to frame it as not intended beyond the scope of that purpose, including by highlighting the non-use of the slash by the serialization algorithm given in the spec itself.

---

/syntax.html ( diff )

[hsivonen]

CC @sideshowbarker @zcorpan

[zcorpan]

I agree the spec should give more context here and be more opinionated.

The example of it not interacting well with unquoted attribute values can be worthwhile to include, but at the same time could have the effect of making people conclude they should stay away from unquoted attribute values (which is OK), and also concluding that then the trailing slash is fine to use.

I think that's not the case. The more important reasoning IMO is that using the / on void elements sets up for a mental model of how the HTML syntax works which is different from how the HTML syntax actually works. That is, people are surprised that <div/> doesn't work, or use such HTML without knowing that the div is not closed as they intended. Case study: contributors to web-platform-tests have made this mistake often enough that I've proposed a lint check for only this HTML syntax error.

[domenic]

Note that this same paragraph was recently changed in #8338 with very similar goals. Maybe it's worth discussing why we think that didn't go far enough, and whether this change will do so.

[sideshowbarker]

https://github.com/validator/validator/wiki/Markup-»-Void-elements#trailing-slashes-in-void-element-start-tags-do-not-mark-the-start-tags-as-self-closing has language that might be appropriate to put into a non-normative Note in the spec:

You can use a trailing slash in a void-element start tag for literally any purpose except to mark the start tag as self-closing.

So, for example, the following are all acceptable reasons for using a trailing slash in a void-element start tag —

• ✅ I use a trailing slash because I like how it looks.
• ✅ I use a trailing slash because I run my HTML markup through a formatting tool that’s hardcoded to add trailing slashes to all void-element start tags, without any option for me to prevent the tool from doing that.
• ✅ I use a trailing slash because I write a lot of JSX code, and JSX requires the trailing slash — without any option for me to prevent JSX from doing that — so for consistency with what I’m accustomed to in JSX, I follow that same style in actual HTML documents.

However, the following reason does not concur with what the HTML standard states —

• ❌ I use a trailing slash to mark start tags as self-closing.

And maybe also something like this:

Using trailing slashes in void elements (and teaching others to use trailing slashes, and making your tools output trailing slashes) promotes a misleading mental model of HTML where the trailing slash looks like it has some special significance — when in fact it doesn’t have any significance at all.