Codebitch : Click to return to MacEdition homepage
 

I am not a MIME artist

July 14, 2003

Feedback Farm

Have something to say about this article? Let us know below and your post might be the Post of the Month! Please read our Official Rules and Sponsor List.

Forums

Want to dig even deeper? Post to the new MacEdition Forums (beta)!

When we redesigned a few months ago, we also made the switch to a XHTML 1.0 Transitional DOCTYPE. It may surprise you to know that some of the most expert of the standards aficionados would disagree with the way we’ve made that switch. It may further surprise you to know that, although I concede the point, I don’t believe that I’ve done the wrong thing.

It’s still valid to validate

Before I get into the nitty-gritty technical detail of this issue, I should recap why validating to a specification is a sensible thing to do. The most obvious is that it reduces the chances that you’ll encounter a browser bug. If your markup isn’t valid, are unexpected renderings the fault of the browser, or the fault of the incorrect markup that the browser can’t cope with? Sure, some error handling is desireable in any software product, especially for browsers, given all the shoddy markup out there. But if the markup is in some sense incorrect, how can you have any expectation of how it should render?

The other selfish reason to try to be valid is that if you do hit a bug, it’s much easier to see what’s going wrong if the page is valid. And if you hit a bug and need to ask fellow Web authors for help, the first thing they’re going to pick up is whether or not your page is valid.

In the past, so-called professional Web designers could get away with all sorts of improperly nested invalid tripe full of quintuply nested tables, spacer GIFs, misspelt attributes and extra closing body tags. But most people know better now. Sure, you’ll see the odd missing alt attribute or unescaped ampersand on some sites. When our pages contain ads from certain banner providers, we’ll have those very problems ourselves (there’s not much we can do about it, either). But valid markup, or at least invalidities of only harmless and trivial kinds, is like the Good Housekeeping Seal of Approval that you know what you’re doing. Increasingly, there are clients who know about the validators and how to put designers’ sites through them. They may not be able to interpret the results, but they will take those results as a mark of your professionalism.

As well as being valid, switching to XHTML has some advantages, too. To my mind, they are mainly of the enforced self-discipline kind. With XHTML, closing your paragraph tags isn’t just encouraged, it’s required. Similarly with list items and other elements that had optional closing tags in old-style HTML. In XHTML, they must all be closed. I consider that a good discipline. It makes the nesting tree structure of the document more explicit. This makes people think about the structure of their documents – a good thing, in my opinion. I suspect it also makes it that little bit easier for browsers to work out the document structure. And of course, if you have any kind of XML-based back end, an XML-based front end can allow so much smoother automation.

Boxed into the invisible phone booth

The fact that XHTML is an application of XML is the reason why some people think that MacEdition is doing the wrong thing. Explaining why requires a little bit of technical detail; if it’s all old hat to you, I apologise. Similarly, if it’s all too hard, I hope my explanation is clear enough.

The document you’re reading has a .php filename extension, so the server knows to interpret the PHP code snippets embedded in the file. So how does the browser know it’s (X)HTML and not some other format like a graphic or a Java applet? After all, you might be viewing the page in an old browser that was published before PHP was invented. (We still get hits every week from CyberDog, you know.) Your browser doesn’t wait to get the file and see if it’s got a DOCTYPE or <html> tag at the beginning.

Without boring you with the details, when the browser sends a message to the Web server to send it a particular file, the server sends back information about the file format, as well as the file itself. In this case, the information it sends is text/html. This is the MIME type.

Because this file is actually XHTML, which is an application of XML, many hold that the correct MIME type for XHTML is application/xhtml+xml or text/xml.

But sending what is otherwise a bog-standard Web page as XML creates all sorts of problems in the browsers that handle XML differently from HTML, like IE and the Mozilla family. One of those differences is, if one of our banner ad providers decides to throw invalid markup at us, the whole page would fail. I can’t enforce validity in markup I can’t control. So letting browsers treat XHTML as XML creates an added layer of complexity that I don’t need. Although some argue that one should send the file as application/xhtml+xml for browsers that can cope with that, and text/html for those that can’t, I just know that would blow up in one’s face the minute one signs up for some other joker’s banner ads, or fails to catch all the crazy things that people can put into a comment posting.

So I send it as text/html and I tell myself that I think that’s a reasonable decision. You can read in the spec that XHTML 1.0 is intended to be useable now and be interpretable by existing, HTML-based agents as if it were old-style HTML. All you need to do is follow some simple guidelines. So why not treat it as HTML in the MIME type? I’m not currently using embedded XML bits like MathML equations in these pages. I’m not authoring to XHTML 1.1 or XHTML 1.0 Strict. Because I’m not advocating standards compliance for its own sake. I’m supporting it because it makes sense. It benefits all users of the Web – authors and readers alike. Standards compliance – by browser developers, authoring tool developers, and authors themselves – simplifies the author’s task.

Remember back when I said that HTML should not be hard? I still believe that. It should not be necessary to be a standards expert – even a standards author – to do the right thing. It should be possible for Web authors to concentrate on what they’re good at – content and design – without having to know how to configure their server. That’s just plumbing, and I am not a plumber. Neither are the thousand of bloggers, of poets, of academics, of journalists. They probably don’t even have that level of control over their servers.

HTML and basic CSS are actually pretty easy to teach to non-specialists. That’s the way it should be, and there’s no point complicating the issue with MIME types. There’s a line beyond which non-specialists shouldn’t have to learn. HTML and basic CSS are arguably on the inside of that line – or maybe not if the Mozilla Composers, FrontPages and DreamWeavers of the world would all get it together and do standards. MIME types are, to my mind, definitely on the outside of that line.

If only full-time standards experts could author a standards-compliant page, there would be something wrong with those standards. Fortunately, there isn’t. It isn’t necessary to get hung up on MIME types, unless you really are doing something that only works in XML. I am not a MIME artist. I’m sending this page to you as text/html.

— CodeBitch (codebitch@macedition.com) is the grumpy cow who does the HTML production for MacEdition. Read other articles by CodeBitch

E-mail this story to a friend

Talkback on this story!

Cannot connect to the database.
Please contact the administrator.