Under parse errors (non-void-html-element-start-tag-with-trailing-solidus) we can find:
"The trailing U+002F (/) in a start tag name can be used only in foreign content to specify self-closing tags. (Self-closing tags don't exist in HTML.) It is also allowed for void elements, but doesn't have any effect in this case."
So the "trailing solidus" isn't an HTML feature but is merely tolerated on void elements.
So the "trailing solidus preference" comes from
wishing that HTML was more like XML (it isn't)
not wanting to remember which elements are void elements but instead desiring an explicit reminder when a tag doesn't support children.
It's one thing to go XML -> HTML (e.g. via XSLT). As the output isn't XML there is no reason to use self-closing tags (as they don't exist in HTML).
HTML -> XML is in many cases a lost cause unless one is prepared to apply Postel's law in bulk - in many cases HTML source isn't even "valid" HTML (example Alpine.js site).
HTML and XML have very different parsing philosophies.
XML parsing:
Is it well formed?
Is it valid with reference to the identified schema?
HTML parsing on the other hand is very forgiving, usually resulting in a "best effort parse" in line with the web's philosophy of resilience and robustness. Given "content is the foundation, markup is an enhancement" it rather show a little bit of "garbage" to the user than hold back any content. That way an error may affect only part of a page while the rest renders as intended.
This robustness also creates some breathing room for innovation - a legacy browser may not know what to do with a web component but that won't affect the parts of the page that are implemented by more traditional means.
The fact that HTML will accept void elements as self-closing tags despite the fact that self-closing tags don't exist in HTML is a testament to its alignment with the "robustness principle" (while XML doesn't tolerate deviations).
So while XHTML seemed like a good idea on the surface its conformance requirement ultimately would have left the web more fragile ("less robust") in terms of encouraging experimentation/innovation and denying users access to all content even in the face of the most insignificant of errors.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
TL:DNR: The HTML standard perspective is:
Self-closing tags don't exist in HTML.
That's an opinion (OK when expressed as such).
The living HTML standard talks about the
brelement and only uses the<br>version.What it does mention: "Content Model: Nothing"
The standard further defines the concept of void elements
All of these are "Content Model: Nothing"
Under parse errors (non-void-html-element-start-tag-with-trailing-solidus) we can find:
"The trailing U+002F (/) in a start tag name can be used only in foreign content to specify self-closing tags. (Self-closing tags don't exist in HTML.) It is also allowed for void elements, but doesn't have any effect in this case."
So the "trailing solidus" isn't an HTML feature but is merely tolerated on void elements.
So the "trailing solidus preference" comes from
So, maybe best to use HTML standard for HTML processing, and convert to XML standard (
) as necessary for integration?
It's one thing to go XML -> HTML (e.g. via XSLT). As the output isn't XML there is no reason to use self-closing tags (as they don't exist in HTML).
HTML -> XML is in many cases a lost cause unless one is prepared to apply Postel's law in bulk - in many cases HTML source isn't even "valid" HTML (example Alpine.js site).
HTML and XML have very different parsing philosophies.
XML parsing:
HTML parsing on the other hand is very forgiving, usually resulting in a "best effort parse" in line with the web's philosophy of resilience and robustness. Given "content is the foundation, markup is an enhancement" it rather show a little bit of "garbage" to the user than hold back any content. That way an error may affect only part of a page while the rest renders as intended.
This robustness also creates some breathing room for innovation - a legacy browser may not know what to do with a web component but that won't affect the parts of the page that are implemented by more traditional means.
The fact that HTML will accept void elements as self-closing tags despite the fact that self-closing tags don't exist in HTML is a testament to its alignment with the "robustness principle" (while XML doesn't tolerate deviations).
So while XHTML seemed like a good idea on the surface its conformance requirement ultimately would have left the web more fragile ("less robust") in terms of encouraging experimentation/innovation and denying users access to all content even in the face of the most insignificant of errors.