Post Archive
› May 6, 2003
The XHTML 100
Can you pass this three level test? Straightforward as it seems, the lack of good results is not entirely unexpected. The three levels are:
- Main page validates
- Secondary page validates
- Content type is sent appropriately to user agents that can take it
In the results, the author states "XHTML is pretty damn hard". I would argue that XHTML is not hard in and of itself, but keeping up with validation can be difficult if you don't have some sort of automated way to do so, or aren't good with the validation habit - that covers test points one and two. Point three is one of the tricker widgets of XHTML publishing, sending the proper content type in the header. This is one of those topics that I've read about but had not followed through on, perhaps others are guilty of the same thing. Thankfully Mark Pilgrim makes it easy to fix if you can install a php or python script, or your web server is apache, find the details in dive into xml. I put the php script on this homepage and on the Movable Type individual archive template, it was so quick and easy that I felt silly for not having done the right thing earlier. How do you know if it's working? First you'll need a browser that supports the correct MIME Type, namely Mozilla, then you can use the live http headers plug-in for mozilla to see your document being served up properly. So, in summary I think this test is very enlightening, and something that should be taken as a wake-up call. Congratulations to Bean Dizzy for being the one alpha geek who definitely passed. If this site was tested, I know it didn't pass, but hopefully now (thanks to the test itself) it would.
As an aside: does anyone have any recommended solutions for better validation? Any automated solutions, for instance ones that send an email to the author?
Comments
1. May 6, 2003 02:09 AM
2. May 6, 2003 03:08 AM
Nate Posted…
Thanks for the tip Lou, that's certainly a good way to remember. This might be an answer for Movable Type users: MTValidate is a plug-in with associated tags and templates. (via the mt-plugin directory)3. May 6, 2003 09:05 AM
Simon Willison Posted…
Serving your XHTML content to Mozilla as application/xhtml+xml is an extremely bad idea unless you are absolutely certain your documents are well formed XML. If they aren't, Mozilla engine browsers will display a big ugly XML error message in place of your site.4. May 6, 2003 09:28 AM
Nate Posted…
Oh right! Ok, perhaps that was the reason I didn't adopt the mime type when I first read about it. I guess in either case, if one has a vigorous validation system, then it would be ok to publish as such? Are there errors the w3c validator won't catch that will cause the mozilla error message to come up?5. May 6, 2003 09:53 AM
Simon Willison Posted…
I don't think so - from my limited experience so far the Mozilla validator seems a lot more forgiving than the W3C one - I think it only flags XML well-formedness errors. The biggest problem I'm having is the weird changes in javascript support. Most annoyingly, the javascript XML checking tool that I normally use to warn me of badly formed XML in my blog entries has stopped working as well!6. May 6, 2003 12:09 PM
Tony Posted…
Level 1 and 2? No problem. I agree. (and pass) I don't agree with the Content Type at all. Not i n the very least. Why? IE. It doesn't deal with application/xhtml+xml very well at all. So now you're stuck with serving alternate MIMEtypes on a browser base. And chances are you're hacking your CSS for different browsers as well. Can you see where this is degrading to? It seems like we're taking several steps backwards with browser sniffers and different sites for different browsers. Screw that. I'll deal with the CSS hacking. I'll deal with the different rendering engines of browsers. I'll deal with all of that. But I draw the line at MIMEtypes. It serves no purpose that I can see. I mean, at this point in time, there isn't a strong reason to be building XHTML sites anyways, other than for personal growth and preparing for the future. So when it becomes important, I'll switch the mime-typel. But not until then. I'm freaking sick of browser-dependent changes.7. May 6, 2003 12:56 PM
Nate Posted…
Tony, I agree with the attitude of your comment, in essence browser detection scripts are better to avoid - very messy and they can get cumbersome. In this case however, Mark's dive into xml article explains that detecting the correct Mime type for XHTML is super simple thanks to mozilla's use of HTTP_ACCEPT. Scroll down on this page: http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html from the dive into xml article to see how simple the script can be, all non-conforming browsers get text/html as the mime type. My main two concerns are: The javascript issues that Simon mentions above (although I'm not enough of a javascript writer for it to effect me yet), and the open question of - will this detection technique work when new browsers arrive? Will IE 12 (or whatever) use the HTTP_ACCEPT protocol. I'm all for complying with standards as closely as possible, but it would seem unrealistic to ignore issues of real world practicality.8. May 6, 2003 03:12 PM
Tony Posted…
That does seem simple. But I think I'm not going to do it out of principle. Plus, what are the benefits of having Mozilla read the correct Mime-Type? I'm probably being just over-bitter about this whole issue. But dammit, I'm sick of kow-towing to browsers.9. May 6, 2003 03:34 PM
Nate Posted…
Just as the author of the test did, I should point to this text document by hixie (safari users, view source to read it). It may be a matter of splitting hairs, or a matter of seeing things from the perspective of browser technology. It seems worthwhile to consider this documents explination of what user-agents actually doing wtih the mime-types fed to them (tag soup, etc). At this point, should we be developing forward enough to a theoretical future where validation is critical to a page even displaying? Are the benifits of tag-soup (forgiving nature) greater than the benifits of must-be-valid XML documents? If we one day have a significant segment of web pages that are reliably valid XML/XHTML documents, what are we going to do with them that we can't do with tag soup?10. May 6, 2003 10:07 PM
Lou Quillio Posted…
I'm with Tony, but my sense is that MIME-type is a (rare) top-level concern. Having made stingy though resolute room for the W3C standards as I understand them, identifying the document type that I'm sending to [not the user-agent but] the user is a concern that won't go away. I know it smells of Microsoft and bloat and kludgy browser apologetics, but I don't know what sort of files I'll be offering users in the future. I would rather tell them than have their user-agents decide. It's a legitimate openness thing. But I'm in no rush, either. LQ11. May 7, 2003 11:40 PM
ksmith Posted…
Hixie's feelings notwithstanding, serving XHTML 1.0 as text/html is not an absolute, according to the spec:'application/xhtml+xml' SHOULD be used for serving XHTML documents to XHTML user agents
The key word 'SHOULD' is defined in RFC2119:
This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
IMO, given the current state of the Web, there are clearly valid reasons to ignore that recommendation.
Lou Quillio Posted…
Any automated solutions, for instance ones that send an email to the author? I get caught only after making some innocuous post that I don't bother to revalidate after. Seems to me that the easiest way to automate revalidation is to pop the W3C validator in a separate browser window upon post save. Because I'll have to close the window, I'll have to look at the validation results. Low tech, but an easy hack to any CMS ... and it would do no more nor less than I'd need. Just now hacked pMachine to do this very thing. Saves me from myself. LQ