HTML and XHTML and Bears, Oh My
James Bennett writes on why HTML is the markup for him. There really isn't anything to agree or disagree with, because he's expressing his personal preferences. To him, the fact that you can co-mingle different vocabularies, such as XHTML, SVG, RDF, and MathML, isn't enough to overcome the draconian error handling (there's that term again, death to the term). Fair enough: XHTML isn't for everyone.
One point of clarification, though: HTML5 isn't just HTML, it's also XHTML5. I know that the specification is misleadingly named, and seems to implicitly promise a path away from XHTML in the future, but I'd hate that those who prefer HTML would close that road for the rest of us; somehow helping to remove the option of using XHTML for those who have worked through the XML error handling in order to reach the advantages of a truly open page markup.
Working through the XML processing becomes less of a challenge as time goes on, as tools undertake the "burden" of ensuring proper markup so that we don't have to be so encumbered. I've found the htmLawed Drupal plug-in to be wonderfully adapted to solving so many of the problems I've had with character encoding in the past. As for generating proper markup in the post, I can either manage the markup myself, which typically consists of paragraph and hypertext links, with an occasional image or SVG document; or I can have the filtered HTML option handle the markup, as it seems to respect and not munge SVG documents.
As for site design, every Drupal theme I've adapted so far has validated as strict XHTML. Makes my job pretty easy.
The point isn't that HTML is better than XHTML, or that XHTML is better than HTML. The point is we all have our preferences, and we should expect browsers to properly handle both—now and in the future.
(via Simon)
Comments
Personally, I prefer HTML 4.01 Strict, read this: Beware of XHTML
But if I download an XHTML Drupal theme, I won't rewrite it :) XHTML does the job fine, too, but I agree with the linked artice above.
By the way, you should not send this page as
text/htmlto Internet Explorer, as W3C stated.I guess I'm a bit agnostic. I'm excited if things are just well-formed which sort of puts me in the xml camp vs html. However, the reality of web pages is that they are broken and in many instances don't conform to anything. So, I want my tools to be pretty forgiving.
I don't think this runs counter to what you're saying. It's just a different perspective.
I do have to say that things like svg are pretty exciting, causing me to think more widespread xhtml support would be nice.
As I think we're both pointing out, the HTML/XHTML debate really should come down to practical "right tool, right job" discussions. For me on my personal blog, HTML is the right tool because I just don't need XHTML and don't particularly want some of the overhead it can introduce.
But in other contexts, for other purposes, it's a different story. At my day job I write software for newspapers, and you can bet we use XML formats and XML tools for that -- the ability to guarantee well-formed, valid data, do arbitrary transformations into various output formats and run XPath queries to pull out subsections of content it just too useful to pass up, and so we've dealt with the attendant complexity of working in XML.
This is why I deliberately tried to avoid things like the draconian error-handling debate: whatever somebody happens to think today, that argument's been effectively over for a good long while.
How would you create a very complex site with lots of Javascript, like Nowpublic.com, in XHTML 1.1?
You should write your Javascript and CSS for
application/xhtml+xmlMIME type. But IE does not handle this. So what would you do?That's why HTML is the best option nowadays...