Look, go ahead and serve up “XHTML” as text/html. Really! So what? Yes, yes, if you actually served up your page with the right mime type so that it actually got parsed as XML instead of invalid HTML, your website would completely fall over. But hey, no worries! Fortunately, you’re not actually using your “XHTML” for anything that HTML 4.01 can’t do, so you can afford to blithely ignore the standard. Unlike, say, Jacques “The Hardest Working Man In Show Business” Distler.
So write some manifestos! Slap those XHTML doctypes at the top of your pages! Go nuts! But before you do so, take some time out to be thankful that there are hundreds of bright, hardworking, underappreciated coders who are designing browsers to clean up after your mess, just as they did for the table/spacer-gif jockeys of yore. I don’t think that’s too much to ask.
Wasn’t it Homer Simpson who once famously said “Can’t someone else do it?”. Of course, he was talking about garbage collection.
I can’t pretend to follow the many XHTML posts but I do support your call for a cosmic pox upon those who not only fail to ‘walk the talk’ but worse yet preach the word while worshipping false idols (if I might be allowed to mix cliches and metaphors).
I like pie.
Page
I like pie too, man. I like pie too.
Sad, innit?
What baffles me is: what, in the education of web developers, is missing, causing them to utterly miss the point of why XHTML was created in the first place?
I mean, do they really think that the W3C went through the trouble of drafting a new markup language, just so that they could introduce the startling innovation of case-sensitive element names and trailing slashes? (Is their notion of “innovation” so impoverished that case-sensitive element names and trailing slashes seem like startling innovations?)
Well, it’s clear why they’re missing the point. It’s Jeffery Zeldman’s fault.
Don’t get me wrong, the Zeldman crowd did a wonderful thing when they started heavily advocating clean semantic markup and CSS-based layouts. It was a far-sighted and gutsy move, given how weak browser support was all those years ago. They deserve a lot of credit for launching the campaign at the right time.
But by choosing to market “clean semantic markup” bundled together with “XHTML”, they confused a generation of web developers. Why did they do this? Maybe they wanted to wipe the slate clean so they could market the new style as a complete “do-over”. Or maybe they simply weren’t technical enough to understand what they were getting into.
So yes, it’s sad to hear newbies say, “I had to redesign my site in XHTML so that I could use a CSS-based layout.” And it’s annoying to read clueless rants like the one I linked to. But ultimately, this is harmless. If people want to serve broken HTML to their clients, and if they want to be blissfully unaware of what is actually going on under the covers, I say let them. The browser devs have them covered.
The only people who are getting bit by this are the people who actually try to use XHTML for something — such a tiny fraction of the population that they aren’t really worth thinking about. 🙂
Oh, and I suppose that if the Killer XHTML App finally arrives — the must-have super-cool piece of technology that every “Web 2.0” site needs to have — well, then a lot more people are going to be bit. And when they figure out they’ve been lied to, they’re going to be pissed.
Also, I do want to reiterate that Zeldman et. al have done wonderful work. Much of the blame really needs to go to the W3C, which has done little or nothing to dispel all the confusion. Honestly, I don’t know whether to be mad at the W3C for wasting their time building standards that no one will ever use, or grateful because the actually useful standards have stagnated for over six years, which has allowed the browser vendors to catch up.
Oh, and the W3C deserves a special dishonorable mention for putting out CSS 2 and other complex, critical standards without shipping any official test suites. What on earth did they expect would happen?
It’s been a lotta years since “Designing with Web Standards.” Heck, IE/7 is in beta, now. You’d think that their consciousness might have evolved a bit since then.
So there’s this thing called “inline SVG”. It’s supported by Mozilla/Firefox, Opera and WebKit (will be in the release version of Safari for Leopard). With a little extra authoring care, it’s supported by IE/6, with a plugin (just as MathML is supported with a plugin).
But, at least in the case of the other browsers, it’s an XML-only technology. MathML may not excite too many people, but surely inline SVG is the sort of shiny new plaything Web developers would love.
If not inline SVG, what killer App would finally make real XHTML rise to the level of something they think they might possibly be interested in?
Inline SVG is never going to be the shiny new plaything for web developers, because Flash won that battle.
As everyone in the valley knows (and as I have confirmed to my satisfaction by talking with ex-Adobe employees), SVG was simply Adobe’s attempt to sabotage Macromedia. Adobe tried to do an end run around Macromedia by pushing SVG through the W3C. But Adobe never had their heart in it, and they certainly weren’t selling any products that fundamentally depended on SVG. Meanwhile, Macromedia was busy shipping code, evangelizing and teaching people how to write Actionscript, and making sure Grandma Millie’s browser had the Flash plug-in included by default.
A “Killer App” is something like VisiCalc. Something that comes out of nowhere, that never existed before, but that makes the whole platform suddenly worthwhile. If Real XHTML is going to take off, it’s going to need some feature that is radically different. Not drawings and animation on the web — that’s a solved problem.
No denying that Flash has been a runaway success.
Still, there is a felt-need for a nonproprietary alternative (hence, e.g., Canvas). So I wouldn’t give up on SVG just yet. It has some prominent backers.
Hmmm, it’s hard to tell how this works in Google Maps, since SVG seems to be an undocumented feature. The closest thing we have is the documentation for “XHTML and VML“, which does advise the developer to use “standards-compliant XHTML”, but only because it “makes layout and behaviors much more predictable across browsers.”
So would your Google Maps VML app break if you served up invalid XHTML? Although their docs are silent about this question, we can infer that since Google’s “XHTML” sample code is broken, the answer is almost certainly “no”.
Although maybe the VML version works in IE because of magical Microsoft XML Data Islands, while the SVG version does in fact require valid XHTML. I guess the only way to be sure is to build an app against this undocumented API and find out.