Home

On the Myths and Realities of XHTML

Shelley on Tuesday, 2008-10-07
Tagged:

Tina Holmboe from the XHTML WG has written a concise overview of XHTML titled XHTML—Myths and Realities. She's provided a nice overview of the markup, including the purpose behind the development of XHTML and the state of XHTML today. The only somewhat jarring note I found about the overview is it seems that Tina went a bit out of her way not to sell XHTML. Perhaps this seeming "you should really need it before using it" push is the reality part of the topic.

I use content negotiation for my sites, serving up XHTML for those browsers and agents that can process XHTML, and HTML for the rest. I'm looking into embedded RDFa into my text in a new iteration of yet another site design, but my main reason for using XHTML is that I like to keep open the possibility of using inline SVG. I also think that support for XHTML seems to be broader than is implied by Tina, but again that could be her trying to downplay any hyperbole about XHTML—there's hyperbole about XHTML?

Though I know this is outside of Tina's overview, I would have like to have more focus on the differences between the HTML5/WhatWG stuff and XHTML 2.0. It's confusing that we have one group working supposedly on an "XHTML 5.0", and another on XHTML 2.0. Especially when one of the main issues to do with XHTML 2.0 was XForms, while a milestone reached with HTML5 recently was the incorporation of Web Forms 2.0—but don't let the "forms" that appears in both fool you into thinking we have any form of consensus or agreement.

I'm beginning to think that the HTML5 working group should completely and thoroughly remove all support for, and even mention of, XHTML from the HTML5 specification. The group finds extensibility to be anathema, but extensibility through namespaces is the heart and soul of XHTML. Seems to me that any form of XHTML, or nod to XHTML, coming out of the group would be a bastard cousin, at best.

Instead of XHTML coming out of the HTML5 group, perhaps we could look at ways to incorporate the new HTML5 objects via namespace to XHTML, but via the W3C XHTML path. In other words, honor the extensibility of XHTML, accept the necessity of a closed world for HTML5 and have one path for HTML, one separate path for XHTML, with the twain meeting via DOM. After all, it's only serialization differences between XForms and Web Forms 2.0, right?

Or, conversely, we abandon the separate XHTML 2.0 path, and incorporate and embrace extensibility into HTML5. But I'm not one to bank on pigs flying.

I'm not a markup expert, nor am I involved in developing browsers, so perhaps my view is both simplistic and naive. But I can't help thinking that the HTML5 working group does not have the mindset or interest in extensibility, and at most, will toss bits of seeming extensibility in to placate the noisy. However, this group's continuing reference to an "XHTML 5" is confusing when you consider there's a separate, formal upgrade path for XHTML 2.0. The W3C says there's nothing to worry about because it's all just serialization under the skin—but it goes beyond just basic serialization techniques, doesn't it? If it were just serialization technique differences, would the same topics keep arising in the HTML5 WG threads? I mean, if working with RDF has taught me one thing, it's that converting between two different forms of serialization is trivial—it's the underlying model that matters.

Really, the W3C is leaving all of this in a bit of a mess.

However, I both digress and am going off on a tangent. This post was about Tina Holmboe's XHTML overview, which is excellent and worth a read.

(via Simon Willison)

And now, for some appropriately themed music...

Comments

Submitted by Bud on Tue, 10/07/2008 - 18:37.

For a *long* time, I was an xml advocate, until we came to browser-based mash-ups and name-spaced xml. Now, I just tell people to use JSON.

The problem with xhtml extensibility is the fact that it uses name-spaced xml. Period. Name-spaced xml is clunky and too fluidly implemented (i.e, too many ways to achieve the desired result, leading to confusion). Parsers can have trouble with it.

I think name-spaced xml came into existence because, at the time, no one had ever taken a practical interest in extending xml documents.


Submitted by Aristotle on Mon, 10/13/2008 - 21:36.

I agree. XML Namespaces as currently specified are robot logic. The problem is that everyone in the discussion is conflating distributed extensibility. I agree with the WHATWG sceptics that XMLNS on the open web is a failure; that doesn’t mean distributed extensibility is.

Now, standards committees are not the place to be conducting design. But given the schedules proposed by the WHATWG for the overall completion of HTML5, I think it quite realistic (and highly advisable) to put distributed extensibility on the agenda – not for right now, but as something for innovators to tackle in the meantime so that we eventually end up with a working proposal that can be absorbed into the ultimate deliverable.

And if DOM-side backwards compatibility with XMLNS can be achieved, even better.


Submitted by Danny (not verified) on Wed, 10/08/2008 - 00:30.

Shelly, nice post.

Bud: So what do propose as a viable alternative to namespaces that allows independent development in a global environment?


Submitted by Bob DuCharme (not verified) on Wed, 10/08/2008 - 09:01.

Hi Shelly,

I realized that XHTML 1 is bigger than many people realize when I went to a local meeting of web developers (see http://www.snee.com/bobdc.blog/2006/03/easy_professionallooking_websi.html) and found that they were all proud to be using XHTML 1. Most of them barely knew the difference between a processing instruction and an XML declaration, but they were so tired of coding around browser differences that that the combination of XHTML and CSS seemed like an obvious path to the future for them, because it provided standards. So personal web sites may not use it, but from what I've seen professional web designers working for paying clients consider it a mark of professionalism to use it.

What I like most about XHTML, and especially XHTML 2, is the greater ability to add proper structure, and of course, metadata via RDFa. More at http://www.ibm.com/developerworks/library/x-xhtml2now.html.

Bob

P.S. Great Jonathan Richman video. He just came to a small place in Charlottesville, but we missed him. In 1979 I saw him join the Necessaries (featuring Chris Spedding and, from the original Modern Lovers, Ernie Brooks) at a party for the Necessaries' manager and do Route 66 and then, with Spedding's Flying V, Roadrunner. It was pretty exciting.


Submitted by Shelley on Sat, 10/11/2008 - 09:23.

I agree on the structure, Bob. And I thought this Richman song and video was perfect, considering the rather "confusing" state of page markup now.


Submitted by Anne van Kesteren (not verified) on Wed, 10/08/2008 - 10:40.

Web Forms 2.0 and XForms differ a lot. They are completely different in the DOM and the difference is not just in serialization, as you suggest.

XForms is a completely new language incompatible with the form controls defined by HTML 4.01 and by extension with the form controls supported by browsers in the XML serialization of XML.

As for XHTML 2.0, that's backwards incompatible with XHTML 1.0 as far as I can tell. Among other reasons because the input element is suddenly an XForms input element which is a completely different beast.


Submitted by Shelley on Sat, 10/11/2008 - 09:25.

"Web Forms 2.0 and XForms differ a lot"

Thanks. Yeah, I knew they were different. So now the W3C is supporting two divergent and non-compatible markup paths. Significantly different markup paths, where not only does the markup differ, but the underlying models differ, too.


Submitted by Anne van Kesteren (not verified) on Sun, 10/12/2008 - 12:49.

Not exactly "now". The W3C has been doing this since it started the work on XForms.


Submitted by Bud on Fri, 10/10/2008 - 07:41.

Danny, you and Shelley raise good points about what it would take to make extensibility possible. I have come to the point where I think extensibility in and of itself is a questionable goal. That question arises out of the difficulty of teaching extensible standards to a large base of people.

At the end of the day, standards have their greatest value when they are widely adopted. That implies super simple and immutable, like ethernet and http.

Believe it or not, I think extensibility in the browser space is now best provided by javascript libraries and fluid data formats like JSON. In that view, html is just a limited way of describing page structure. Javascript alters it dynamically and adds functionality. I'd put svg support directly in javascript.

Please understand that these are just opinions borne from the teaching trenches.


Submitted by Shelley on Sat, 10/11/2008 - 09:27.

The point is, we shouldn't be selling extensibility at the markup level, we should sell it at the end-user level.

And JSON and JavaScript cannot make up for having an extensible markup. Seriously, I respect your opinion, but must disagree with you on this one.


Submitted by Bud on Sun, 10/12/2008 - 09:39.

I'm not sure I'm so much adopting a position as raising issues.


Submitted by Aristotle on Mon, 10/13/2008 - 21:22.

Forcing SVG in via Javascript is a gross violation of the the principle of least power.

I thought HTML5 was expressly trying to restore some balance by providing markup facilities for things (like date inputs) that everyone is currently hacking in via Javascript. Does your proposition amount to the statement that we will have to hack SVG in via Javascript for the next decade so that WHATWGng can one day be convinced of its necessity?