Minor quibble: level 6’s code uses </input>, which is invalid in HTML syntax (though harmless): <input> is a void element, meaning it can’t have any children and has no end tag.
(You could write <input/>, the old XML syntax for self-closing tags, but I strongly recommend against doing that because it teaches a wrong mental model: that trailing slash is permitted in HTML syntax on void elements for XHTML compatibility but does not close an element: it’s just ignored.)
I strongly recommend against doing that because it teaches a wrong mental model
What's wrong with using XML as the underlying mental-model for HTML5 (HTML "Living Standard", etc)? HTML still supports XHTML and (to my knowledge) the only appreciable difference between HTML and XHTML is the requirement that the HTML tag soup be a well-formed XML document. That's it. XHTML is still valid HTML, and XML's model is simple and easy to understand and covers 100% of HTML's use-cases.
The difference between XHTML today vs. back in 2005 was that the W3C grossly underestimated the extent at which modern tooling will continue to generate invalid HTML markup (let alone any truly semantic HTML markup either), so web-browsers and scrapers needed to be more forgiving in their input processing and also standardise how they interpreted invalid HTML. None of that precludes us from writing software to a higher standard: software which generates valid XHTML which allows HTML to be handled by existing XML-processing infrastructure (and even serialized to JSON if you're crazy). What's "wrong" about any of that?
It teaches the wrong mental model for the HTML syntax. If you’re using the XML syntax, by all means use self-closing tags, but very few things do that, and almost all of them are over a decade old. (I set up gitweb last week, and it uses XML syntax HTML, and needs it because it nests links, which is invalid but works in XML syntax, and impossible in HTML syntax. It also does other wrong things like omitting the <tbody> in tables, which is inserted automatically in HTML syntax.)
What I observe is that it’s quite common for people to put in the trailing slash on void elements, but that it’s almost never (<1%) applied consistently (you’ll see some <link/> and some <link>) so that any XML syntax compatibility argument is void, and I’ve come across at least one person who thought it was necessary and at least one person who thought it closed tags (and thus could be applied to non-void elements) and was surprised that it didn’t.
XHTML is dead. XML syntax for HTML is on indefinite life support (with no prospect of being either revived or removed). HTML is not XML: the HTML and XML syntaxes are mutually incompatible (e.g. <noscript> isn’t possible in XML syntax, and <script>"&"</script> produces a different result). Writing your HTML in more XMLy ways isn’t about higher standards, but about making it something that it’s not. It’s wrong to use XML processing infrastructure on HTML documents unless they’re marked as XML syntax, because even if it doesn’t fail, it may interpret things incorrectly.
Comments
Minor quibble: level 6’s code uses </input>, which is invalid in HTML syntax (though harmless): <input> is a void element, meaning it can’t have any children and has no end tag.
(You could write <input/>, the old XML syntax for self-closing tags, but I strongly recommend against doing that because it teaches a wrong mental model: that trailing slash is permitted in HTML syntax on void elements for XHTML compatibility but does not close an element: it’s just ignored.)
What's wrong with using XML as the underlying mental-model for HTML5 (HTML "Living Standard", etc)? HTML still supports XHTML and (to my knowledge) the only appreciable difference between HTML and XHTML is the requirement that the HTML tag soup be a well-formed XML document. That's it. XHTML is still valid HTML, and XML's model is simple and easy to understand and covers 100% of HTML's use-cases.
The difference between XHTML today vs. back in 2005 was that the W3C grossly underestimated the extent at which modern tooling will continue to generate invalid HTML markup (let alone any truly semantic HTML markup either), so web-browsers and scrapers needed to be more forgiving in their input processing and also standardise how they interpreted invalid HTML. None of that precludes us from writing software to a higher standard: software which generates valid XHTML which allows HTML to be handled by existing XML-processing infrastructure (and even serialized to JSON if you're crazy). What's "wrong" about any of that?
It teaches the wrong mental model for the HTML syntax. If you’re using the XML syntax, by all means use self-closing tags, but very few things do that, and almost all of them are over a decade old. (I set up gitweb last week, and it uses XML syntax HTML, and needs it because it nests links, which is invalid but works in XML syntax, and impossible in HTML syntax. It also does other wrong things like omitting the <tbody> in tables, which is inserted automatically in HTML syntax.)
What I observe is that it’s quite common for people to put in the trailing slash on void elements, but that it’s almost never (<1%) applied consistently (you’ll see some <link/> and some <link>) so that any XML syntax compatibility argument is void, and I’ve come across at least one person who thought it was necessary and at least one person who thought it closed tags (and thus could be applied to non-void elements) and was surprised that it didn’t.
XHTML is dead. XML syntax for HTML is on indefinite life support (with no prospect of being either revived or removed). HTML is not XML: the HTML and XML syntaxes are mutually incompatible (e.g. <noscript> isn’t possible in XML syntax, and <script>"&"</script> produces a different result). Writing your HTML in more XMLy ways isn’t about higher standards, but about making it something that it’s not. It’s wrong to use XML processing infrastructure on HTML documents unless they’re marked as XML syntax, because even if it doesn’t fail, it may interpret things incorrectly.
Long live XHTML syntax for self-closing tags!
Good point - fixed it :)