Help developers better understand self-closing-tag syntax #8338
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem description
Many web developers have misunderstandings about self-closing-tag syntax in HTML documents. Discussions in Stack Overflow and Twitter threads and various other fora provide evidence of those misunderstandings.
Specifically, many developers misinterpret the
/
solidus character in an HTML-element start tag to mean that the HTML element is marked as self-closing — when in fact the HTML standard does not actually say that it marks HTML elements as self-closing but instead only marks foreign elements (SVG and MathML elements) as self-closing.Some tool vendors — that is, some vendors of HTML formatting and authoring tools — also seem to have that same misunderstanding, which has resulted in a proliferation of tools (most notably, Prettier) that bake self-closing-tag syntax into the behavior of their tools in a way that also further proliferates misunderstandings among web developers.
On top of that, most developers are likely not aware that the
/
solidus character, if directly preceded by an unquoted attribute value, becomes part of the attribute value rather than being discarded by the parser.For some related discussion that makes some important points about why all that is a real problem for developers and why we should try to help solve it, see @hsivonen’s comments at https://github.com/orgs/mdn/discussions/242#discussioncomment-3749398 and at https://github.com/orgs/mdn/discussions/242#discussioncomment-3759664.
Proposed solution
Refine the wording of the relevant text in the HTML standard to:
Clarify that the
/
solidus character in an HTML-element start tag doesn’t mark the HTML element as self-closing.Explicitly caution developers that the
/
solidus character, if directly preceded by an unquoted attribute value, becomes part of the attribute value rather than being discarded by the parserNotes
The relevant existing text of the HTML standard says this:
Note carefully: that text in the standard explicitly states that the
/
solidus character marks foreign elements as self-closing but that same text very intentionally (not an oversight) does not state that it marks void elements (which are elements in the HTML namespace) as self-closing.In other words, since the standard does not explicitly state that the
/
solidus character marks void elements as self-closing, that means it in fact does not mark void elements as self-closing.However, to a casual reader, that existing text in the standard risks being read with ambiguity — which is perhaps part of what’s lead to some of the misunderstandings about it among developers.
Therefore, the patch in this PR branch aims to make the relevant text in the standard unambiguous — by clearly and explicitly stating that the
/
solidus character does not mark a void element as self-closing (which is consistent with what’s already stated and intended by the existing text in the standard).All that said, I’m not wedded to the exact wording in the initial patch in this PR branch, and would be happy if we could use this PR to iterate on any refinements to the wording that we could get rough agreement on — as long as the wording we arrive at helps to solve the problems described in the Problem Description above, and as long it includes conveying the two key points outlined in the Proposed Solution above.
/syntax.html ( diff )