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.
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.