Hi folks!
I learned about XHTML lately. It seems that XHTML is mostly identical with HTML, but stricter. Therefore it works for more browsers, especially for small devices like mobile phones. So I asked myself, wouldn´t it make sense to practice XHTML from the beginning? And if so, why is it not common practice and everyone does it?
Everything defined in XHTML is available in HTML5. The inverse is not true. HTML5 subsumed all of XHTML. Everything available in XHTML works in HTML5, but if you restricted yourself to that subset, lots of things are not available (the successor to XHTML, XHTML2, despite having some excellent features, was not backwards-compatible, was never finalised, and died). HTML5 is the current standard, there isn’t a lot of point teaching the previous standard.
This is kinda true if you want to support extremely old browsers. You have to go back quite a long way in terms of browser versions before this is an issue though, for major ones you’re looking at ~10 years for most major features.
For mobile, not really true, as HTML5 was designed to work better on low-powered devices.
Going by that logic, why not practice HTML4? Almost everything in HTML/CSS/JS has to remain backwards-compatible, so anything written under HTML4 constraints will still work fine, even though it’s 22 years old now.
3 Likes
HTML5 has an XML “serialization” (as the spec calls it), which handles the role that XHTML did previously. It’s mostly useful for embedding into other XML docs, but I’ve never seen it in the wild for creating web pages. It’s worth noting that HTML5 is its own thing now, and is not even SGML-compliant like previous versions were.
You could always teach yourself some XML and dabble with the XML serialization of HTML5, but other than satisfying curiosity, there’s really not much general use you’re going to get out of it. I think you’ll find with both legacy XHTML and the XML serialization that you’ll find fewer things it’s compatible with, not more.
2 Likes
At this point, as others have said HTML5 includes the XHTML specification.
The few points I have to add:
I prefer to close all tags, and have found that doing so I was bit more ready for React. I think it is a better practice to include the / in self closing tags. That’s just me though.
If you end up doing email dev, know XHTML is a must. While in the last two years we’ve got to use the HTML5 Doctype more, XHTML and HTML 4 is more widely supported in email clients. Often, this is what catches web devs who find themselves working in email…HTML5 is still mostly a pipe dream at this point in the email world.
2 Likes
Why not learn HTML4, haha! I can see things more clearly now, thank you 
Thank you, I think I am going to close the selfclosing tags, too, seems like a good practice. So, XHTML is not completely useless after all.
The only reason to add the slashes, e.g. <br/>
is if you’re trying to be compatible with XHTML or JSX, which do require the slash. HTML5 will allow it, but you should know that <br>
(or <link>
or <input>
and so on) is still perfectly valid syntax, and any decent editor that understands HTML should still indent correctly when you leave the slashes out.
Oh, and just to make things extra “fun”, sometimes a self-closing tag isn’t an acceptable substitute for a pair of tags, even when the content is empty. Try <script />
vs <script></script>
sometime and you’ll find you’re forced to use the tag pair.
I personally find the extraneous trailing slash to just be extra noise, but opinions differ. Whichever way you choose, just be consistent about it.
1 Like
Thanks buddy, so I am going to be consistent 