XHTML? Huh. What is it good for?
Oh joy! Zeldman has an article on XHTML at A List Apart! Surely this time he will list some actual, real benefits. With trembling fingers I click Meryl‘s link, only to be disappointed once again. While it is true that a multitude of links to the NYPL Style Guide will convince Google of its importance, no amount of linking can change the fact that there are no benefits, and real drawbacks.
To recap my take on the Zeldman/Bickner list of benefits: they hope that you will actually validate your XHTML pages, so you won’t use improper nesting of tags or forget to close tags, and maybe someday someone will write something or build something that understands XHTML but not HTML.
Perhaps the W3C has some explanation of benefits, after working on XHTML for a couple of years? From the “What is XHTML?” section:
- XHTML documents can be viewed, edited, and validated in XML tools. Do you have an XML tool? I certainly don’t.
- XHTML documents can be written to operate as well or better than they did before in existing HTML 4-conforming user agents as well as in new, XHTML 1.0 conforming user agents. This is a benefit? “It’s possible (but not certain) that switching to XHTML won’t make things worse.” Gee, thanks.
- XHTML documents can utilize applications (e.g. scripts and applets) that rely upon either the HTML Document Object Model or the XML Document Object Model [DOM]. I’m willing to believe that this is somehow a real benefit, to those who already know what the hell they mean, and as soon as I find a good script at XML DOM Scripts4U and another at HTML DOM Scripts Galore that I want to put in one page, I’ll hop right on the XHTML bandwagon. (God, almost wet myself: it’s a miserable task to design a page that uses one DOM, much less two.)
- As the XHTML family evolves, documents conforming to XHTML 1.0 will be more likely to interoperate within and among various XHTML environments. Translation: “We are in the business of designing new specifications, and we aren’t about to stop doing it. If you start using this one, maybe it won’t be quite as hard to jump to the next one.”
Apparently realizing that these “benefits” weren’t, they included a separate section, “Why the need for XHTML?” An excellent question. The answers:
- XML allows for the addition of new elements and attributes, and XHTML Modularization is supposed to make it easy to add to XHTML. In fact, two years later, XHTML Modularization is attempting to take things away from XHTML 1.0, rather than add things.
- At the time (remember, XHTML is two years old), “Alternate ways of accessing the Internet are constantly being introduced. Some estimates indicate that by the year 2002, 75% of Internet document viewing will be carried out on these alternate platforms.” The theory seems to have been that your webserver would decide what parts of your XHTML page to send based on the user-agent: perhaps sending a tiny monochrome image to a PDA, or leaving out the links in a page sent to a proxy for a one way push only wireless device. An interesting dream, and if it comes true in 2010 or 2020, I’ll be sure to make the switch, after I know what I really need to change.
How about the drawbacks? Here are a few:
- XHTML requires that all tag names be lowercase. If you happen to like using uppercase tags to make them stand out from the content, tough. If you use a tool that produces uppercase tags, tough.
- XHTML requires that all attributes have a value, so rather than use
checkedyou must usechecked="checked". When that breaks an older browser, tough. - All those thousands of <a name=”foo”> anchors you’ve put in your pages, for permalinks and for section navigation in non-blog pages? Sorry, XHTML prefers that you use id=”foo”, despite the fact that most browsers won’t navigate to <a id=”foo”>. If you are doing XHMTL 1.0 you may use <a id=”foo” name=”foo”>, but if you want to do XHTML 1.1 you must use <a id=”foo”> without the name=”foo” that will allow it to actually work. Tough. While you are at it, they must be unique within the document, and they must start with a letter. If you use a tool that produces permalinks that start with a digit, tough.
- Like to hide your style sheets and scripts from older browsers by enclosing them within comments? I don’t know what browsers you are actually hiding them from, but, tough: XML parsers are allowed to remove comments completely, so you can’t do that anymore.
So in XHTML we have a markup language with no benefits, for which there are no specific user-agents, which has several drawbacks, and for which conversion from the widely (if imperfectly) known HTML standard may be easy but is not instant. To me it sounds perfect for underemployed web designers, and completely useless to anyone else.
XHTML is too much of a fudge between HTML and XML … and it’s true that there aren’t many great benefits.
Yes, it’s only a geek update of HTML – making it more syntactically correct for XML guff – but I like that.
However, it _is_ just the next version of HTML so any benefits would be minimal anyway. Most of the time they just add problems into new versions that take a while to fix.
ok, i know you read my response on the greymatter forums but i just got around to reading your entry about this. true that XHTML 1.0 and up have drawbacks such as all lowercase tags but if you write or define your own tags, you can make them uppercase, lowercase or both if you feel like it. IMO the main reason XHTML is around is to help extend HTML in the many ways XML is and is being expanded. in XML, if you want to code your blog and have a specific tag for the by line, all you do is drop that in the code and put it in your schema. it’s just as easy to do with XHTML except if you use DTDs, it’s a bit more archaic (sift through the code on my personal site for 3 instances of new tags). if you tend to delve into XML and write it frequently, XHTML is a breath of somewhat fresh air.
true, it’s syntatically similar to HTML 4.01 but also has it’s ties with XML. these help to offer cohesion between the two standards. after a day of pounding out XML code and writing schemas, it’s nice to come back to XHTML and see the familiar HMTL elements in use but also nice to be able to utilize those skills in XML.
but, that’s just me.
Phil, no offence, but regardless of how thin you think the arguments are for XHTML, your criticisms and attacks are even thinner. You briefly mention the ALA article in your opening statement, but then spend the majority of your rant slamming the W3C for coming up with XHTML. Your list of drawbacks comes off like a lot of ill-informed, self-important whining. To wit:
1. XHTML requires that all tag names be lowercase. If you happen to like using uppercase tags to make them stand out from the content, tough. If you use a tool that produces uppercase tags, tough.
How I weep for your failing eyesight that you can’t distinguish a tag from content. I also feel bad that you can only afford to make use of tools that don’t afford you any flexibility. Then again, hand coding was so difficult, wasn’t it?
2. XHTML requires that all attributes have a value, so rather than use checked you must use checked=”checked”. When that breaks an older browser, tough.
I use it all the time and have yet to see a browser break. What browser are you using?
3. All those thousands of <a name=”foo”> anchors you’ve put in your pages, for permalinks and for section navigation in non-blog pages? Sorry, XHTML prefers that you use id=”foo”, despite the fact that most browsers won’t navigate to <a id=”foo”>. If you are doing XHMTL 1.0 you may use <a id=”foo” name=”foo”>, but if you want to do XHTML 1.1 you must use <a id=”foo”> without the name=”foo” that will allow it to actually work. Tough. While you are at it, they must be unique within the document, and they must start with a letter. If you use a tool that produces permalinks that start with a digit, tough.
This is absolute nonsense and nothing but disinformation. To say that ”most” browsers won’t navigate to a unique ID in a document is incorrect. NS4.x won’t do it. Big deal. NS4.x doesn’t do a lot of things. And what’s the matter, you forgot how to use the alphabet to stick a letter in front of your <$BlogItemNumber$> like this:
<a href=”archives/<$BlogItemArchiveFileName$>#p<$BlogItemNumber$>”>
That was difficult wasn’t it. Definitely worth a line or two in your rant.
4. Like to hide your style sheets and scripts from older browsers by enclosing them within comments? I don’t know what browsers you are actually hiding them from, but, tough: XML parsers are allowed to remove comments completely, so you can’t do that anymore.
Again, nothing but disinformation. If you knew and understood the spec you’d know that you could define the following:
<style type=”text/css”>
/*<![CDATA[*/
body {margin:0;}
/*]]>*/
</style>
and you would have no errors using this syntax in browsers back to NN3.
I don’t see your problem Phil, I really don’t. You’re willing to argue for CSS in your role as ”blog troubleshooter” but not XHTML. Why is that? I’ve seen countless Blogger errors related to improper nesting of tags. I know you’ve seen it too. You like your Blogger strict but not your HTML, huh?
Damn, and I was just thinking the other day how much I missed you. You surly bastard.
The question is not whether I can do it, of course I can. The question is whether everyone should do it, and whether they should go back and redo all their old stuff.
Lowercase? I cribbed that from PPK’s article in A List Apart. I don’t use uppercase tags myself, but if a Javascript God wants to, and no web browser or device currently made has a problem with it, why shouldn’t he?
Why on earth would I deny NN4 the ability to navigate to permalinks, just because the W3C decided that name wasn’t a good attribute? The web is supposed to be backward-compatible, and if you are going to break something, you should have a reason for breaking it beyond ”we don’t like that anymore”.
I’ve seen countless errors related to improper nesting of tags, which is just as invalid in HTML as it is in XHTML. You’re just making the same argument I accuse Zeldman of making: ”people can’t be bothered to write valid HTML, but maybe if we convince them that validation is part of XHTML, they’ll pay more attention to what they are doing.”
My problem is that people are spending time converting pages to XHTML, doing things with no practical value, because they’ve been misled. The forum that fosh is talking about was a post from someone who had converted her Greymatter blog to XHTML because she thought that would make it printer-friendly and wireless accessible, and she wondered why nobody had refuted me. The only answer I’ve gotten so far is fosh’s: if you use XHTML you can write your own DTD and create your own tags, so that you can use <byline> rather than <span class=”byline”>. That’s cool, for those who want to, but it’s not going to persuade me that I should encourage people to make the switch.
If XHTML was being marketed as a way to write XML that can be understood by most modern browsers, if you happen to need your web pages in XML, that would be fine by me, but it’s not. It’s being marketed as the way to write HTML, and you damn well better stop using that old stuff right now.
You know what my real problem is? XHTML, CSS-3, pretty much everything the W3C is doing anymore, seems to be designed to be completely incomprehensible to the average user. Throw in a few more things like ”/*<![CDATA[*/” and ”body > h2:not(:first-of-type):not(:last-of-type);” and no ordinary people will be handcoding anymore: they’ll all be using tools sold by the members of the W3C.
Anyway, what have you been doing with yourself all these months?
Damn, and I was just thinking the other day how much I missed you. You surly bastard.
heh. Sorry about that.
I don’t recommend XHTML for people creating personal pages or blogs. In fact I usually try to turn them off from it. If someone understands what XHTML is and still wants to code to it, that’s fine, but as for it catching on as a fad, or people using it as personal flag waving in the blogging community, that is not zeldman’s, ALA’s, or the W3c’s fault. As I used to do in the Blogger forums, and as I’ve always done, I recommend people simply learn good coding practices and write valid code.
And btw, you know that XHTML is backwards compatible under transitional. It’s only in the strict sense that things become non-backwards compatible. That is just as true for HTML as it is for XHTML. I’ll grant you that losing something as entrenched as the name attribute may be a bit harder to swallow, but as technology progresses things will change. Things have changed in ways no one predicted. I can fault the W3C for not being more omnipotent.
Are things getting more complicated? Yep. And the range of what HTML/XHTML/XML can do is extending. But I believe the average user can learn to do whatever they really want to do. They’ve learned things as simple as HTML to things as complicated as JavaScript and Perl when they needed to. As far as using tools, we may all be using them at some point. As things become more and more like strongly typed code, tools that make the work easier will become invaluable.
I see it as an evolution of the medium. I certainly don’t want to see the medium ripped out of the hands of the average user, but I don’t see that happening. People screamed an yelled when the first visual editors arrived on the scene. But these ”tools” are exactly what put the power in peoples hands. After all, how many ”average users” do you know that hand code anything? I’m quite certain that the evolution of these tools will be in line with the evolution of the medium.
I agree that right now, XHTML/XML is for the designers and professionals, but the W3C, zeldman, et al, have every right to spread the word about it through the design community, which is where they are spreading it. Zeldman is a designer speaking to designers. He is not a Blogger preaching the merits of XHTML to other Bloggers. Those Bloggers that enjoy web design may want to learn more about XHTML, but no one is forcing it down anyone’s throat.
If in the end your argument is that XHTML is not for newbies and a waste of time for the average Blogger, I’m inclined to agree with you. If however, you really don’t see the what XHTML has to offer in extending the vocabulary, and your only comments are derisive rants, then I’m going to be vehemently opposed.
oops…that should be ”I <em>can’t</em> fault the W3C for not being more omnipotent.
I find it somewhat surreal to be reading this post 5 and a half years after it was written and knowing that the status quo hasn’t really changed (even if the details have). Instead of having to work around the old and less popular NS4, authors now have to lie about mime types to the new and relatively popular IE7. ”Write XHTML, then lie to IE so it doesn’t try to process it as XHTML” is hard to justify in my budget. I guess it could be worse, what with people writing excited articles about XHTML2, with headlines like ”goodbye compatibility.”