XHTML

We've decided that IE8 will, by default, interpret web content in the most standards compliant way it can. This decision is a change from what we've posted previously.

What a bizarre concept, to support standards by default.

To clarify the situation, I asked Chris Wilson what would happen if IE8 were to encounter a valid, well-formed document with a strict DOCTYPE. My worst fears were realized when he confirmed that the browser would behave exactly as if it were its predecessor.

This is gobsmackingly audacious. Imagine a new version of Word that behaves exactly like the old version of Word unless the document it is processing contains a hidden instruction to unlock any new features. That's what Microsoft is demanding that web developers implement. Unless you explicitly say otherwise, IE8 (and IE9 and IE10, ad infinitum) will behave exactly like IE7.

The Drupal Handbooks are an exhaustive resource for learning all things Drupal. Unfortunately, sometimes finding just the information you need can be difficult. The Theme Developer's Guide alone includes 14 sections, most made up of additional sub-sections.

With that in mind, I put together a Drupal Theme Developer's Cheat Sheet that includes some of the most handy reference information for themers.

Local mirror of Drupal Theme Developer's Cheat Sheet

Note that HTML5 in no way required Ogg (as denoted by the word "should" instead of "must" in the earlier draft). Adding this to the fact that there are widely available patent-free implementations of Ogg technology, there is really no excuse for Apple and Nokia to say that they couldn't in good faith implement HTML5 as previously formulated. Throw your own theory here: DRM, proprietary control, et cetera.

The WHATWG had an opportunity here to eliminate the plugin morass (so 90's) in favor of a baseline format that each browser could implement. Just as HTML specified baseline formats for images (GIF and PNG), this should have been an opportunity to specify baseline free audio and video. And there's still a chance.

Please, please help this issue get more public scrutiny. Use whatever means you deem necessary. Exert pressure on the WHATWG (subscribe now, let your thoughts be read). Don't let special interests kill computing for all — now it’s time to take a stand!

On their mailing list, so far:

• [whatwg] Removal of Ogg is *preposterous*
• [whatwg] Removal off Ogg technology

Though even if the spec were written to reccomend (or even require) Ogg, since when did people actually code their websites to validate? It's been how long since we said "to hell with bad browsers"?

Nokia has filed a submission with the World Wide Web Consortium (W3C) objecting to the use of Ogg Theora as the baseline video standard for the Web. Ogg is an open encoding scheme (On2, the company that developed it, gave it and a free, perpetual unlimited license to its patents to the nonprofit Xiph foundation), but Nokia called it "proprietary" and argued for the inclusion of standards that can be used in conjunction with DRM, because "from our viewpoint, any DRM-incompatible video related mechanism is a non-starter with the content industry (Hollywood). There is in our opinion no need to make DRM support mandatory, though."

...

So DRM is by definition proprietary. If it's not proprietary, it can't be DRM.

And, of course, Ogg Theora is not proprietary. It does have some patents covering it, but those patents have been surrendered, to all intents and purposes.

...

Some Slashdot commenters have pointed out that they have technical problems with Ogg Theora. That's a valid discussion to have -- if the W3C is going to pick a video codec, its technical merits should be discussed. But remember, that's not what Nokia is objecting to: they are arguing that Ogg is proprietary (it isn't) and that DRM should be part of a Web standard (it shouldn't). PDF link to Nokia's W3C submission, Link to Slashdot comments.

Local mirror of Nokia's submission to W3C regarding Ogg Theora

Actually, the first issue I have is that it's called a weblog API....it's a CMS API, or maybe just a publish-editing API. We're stuck in this concept of "blog". With structured blogging (yep, that damn word again...but I guess that's what you get when all you have is one big text blob to shove data structures into*) just on the horizon, tools like ecto, Qumana, and MarsEdit are going to be pushed to work with the myriad number of web apps out there, and the different ways they've implemented some of the loose aspects of these APIs.

...

Why the rant about blogging and "big text blobs"? Well, I'm biased by my tool of choice, Drupal. We've got separate content types for structured information, like events or reviews, and so don't need to take a step back and find ways to mark up structured information inside text. Of course, we'll support structured blogging standards and formats as they arise (and yes, those funky XHTML level microformats, too). Canter's Law, and all that.

...

Heck, if those large players want to come along and crawl my standard RSS 2.0 categories, they can win by giving us kick ass interfaces and great tools for slicing and dicing. But I'm not going to work with your made up formats, I'm going to work towards global standards that work for everyone.

Everyone has heard of the latest standard, XHTML. Pretty much every blogger proudly displays his or her tag of validation, maybe even a valid CSS tag as well. That's good and fine, but are you serving the document as an XML document or just as tag soup?

First, for almost all people, there is no reason to serve documents as anything else but tag soup. The XHTML specification states that for HTML compliant XHTML 1.0 you should serve documents as application/xhtml+xml but that you may serve documents as text/html. For any other document types, such as XHTML and MathML, you may not serve the document as text/html, but still should serve documents as application/xhtml+xml.

Why would you serve a document as XML?

Sort of. HTML is fine for the average website. But what if you need to include another XML subset, such as MathML, in your document? The Guide For Authoring MathML For Mozilla says this about authoring MathML pages:

For a MathML fragment to be rendered in Mozilla, it should be a well-formed XML fragment within a well-formed XML document.

Mozilla is XML 1.0 compliant and can render XML pages that are styled with CSS or XSLT. Different XML vocabularies can be mixed in the same XML document, and each vocabulary will be distinguished by its namespace. Mozilla supports XHTML documents, the format of choice when serving MathML fragments embedded in other text.

Because of the limitations of HTML, the W3C is now backing XHTML and is not considering doing any major work on HTML anymore. XHTML (eXtensible HTML) is a reformulation of HTML in XML. Contrary to HTML where sloppy markups are tolerated, ill-formed XML (and thus ill-formed XHTML) documents are not rendered.

There's a few parts in there that jump out. The first is that MathML fragments must be a code fragment within a well-formed XML document. That means none of my pages can be tag soup, they must all be well-formed XML. Pushbutton, the latest theme for Drupal comes very close. I've only seen a handful of instances where there wasn't well formed XML and I fixed those in about half an hour.

The other part is that ill-formed XML documents aren't rendered. What that means is that, unlike HTML rendering, XML rendering isn't even attempted if there is one tiny error. Not closing a tag, not using the proper entity for an ampersand, anything that makes it invalid and the entire page is replaced by an error message. Not good if Joe Internet-User will be leaving comments here, he could break any page at his will just by posting an ill-formed comment.

mezzoblue goes into detail about this in his entry, Bulletproof XHTML:

However, Jacques soon discovered that he was Living On A Knife's Edge. Because he was using Mozilla's unforgiving XML parser, one little mistake, a mismatched tag, an unescaped entity, would choke his visitor's browser. And to his consternation, Jacques found that even if he wrote perfectly well-formed XHTML, other people were conspiring to mess up his web pages. By allowing comments, opening up trackbacks, and displaying snippets from alien RSS feeds, Jacques had opened up his site for any random visitor to crash that page with garbage markup. In order to produce 100% valid XHTML, Jacques realized that he had to "bulletproof" his site. Strip control characters. Validate comments. Batten the hatches. If he was going to take advantage of the power of XHTML, he would have to protect his site from his own mistakes and everyone else's.

OK, so all I've got to do is change how the documents are served and I'm good to go?

Nope. Internet Explorer craps out on on XML. Just doesn't do what it's supposed to. Any IE users can go to MozillaQuestQuest and they won't see a website, just a DOM tree. It's not the site that's broken, it's the browser. So we need to do some browser sniffing. I made use of the example found at Keystone Websites and changed Drupal's /includes/common.inc around a bit. This is what it had:

// spit out the correct charset http header
header("Content-Type: text/html; charset=utf-8");

And this is what I changed it to:

// spit out the correct charset http header
$mime = "text/html";
$charset = "UTF-8";
if(stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml")||
         stristr($_SERVER["HTTP_USER_AGENT"],"Validator")) {
                $mime = "application/xhtml+xml";
}
header("Content-Type: $mime;charset=$charset");

Basically, if your user agent accepts XHTML or if you are a validator, I give you a application/xhtml+xml document, but if you're anyone else, such as IE, I give you a text/html document so you don't flip out and act all stupid.

But didn't you say that for something like MathML to be rendered, it must included in a well-formed XML document? What about IE users who want to see the included MathML?

Well, IE users can either get a real browser, such as Firefox or they can get the MathPlayer Plugin, which lets IE render MathML code fragments inside a plain HTML document.

OK, are you done now?

Nope. People here have to preview their comments before they go live. IE users will preview their ill-formed tag soup and go on with their lives, leaving the Mozilla users to see nothing but an error message when they try to view the same page. I need to work on a way to validate comments before letting them be submitted. If Movable Type can do it at Musings than Drupal should be able to as well. With Drupal's community plumbing, it could easy become courseware (with math, engineering and physics students in mind), making use of features that Movable Type lacks, such as the powerful taxonomy and book features.