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!
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.