If there’s one tool that has really helped with the adoption of web standards over the years, it’s the W3C’s HTML validation service. We all make mistakes in our code on a pretty frequent basis, and having a tool to help us catch those mistakes improves the quality of what we’re publishing. What’s more, it gives us the confidence that what we’re publishing is of good quality, which is rewarding in itself. As web developers, running our code through a validator has become a pretty standard part of our daily workflow.

So when it comes to microformats, a frequent questions is where’s the validator? Truth be told, writing a validator is a fiddly task. Writing a really good validator is hard. That aside, it raises the question of whether writing a validator for microformats is even possible at all.

Consider the situation with validating a tag-based language like HTML. The rules state which elements can be used, and for each element what attributes are acceptable. It’s clear to see that, in principal at least, that should be relatively straightforward to express in software. In such a situation, I know that if I come across a tag with the name H7, I can see that H7 isn’t in my list of allowable elements and therefore it’s an error.

With microformats, however, we’re embedding a dialect inside HTML. Whilst it’s easy to spot items that are part of that dialect, it doesn’t hold true that anything not recognisable as being of that dialect is an error. To take an example for hCard, I might have an image with a class name of photograph as part of an hCard block. The official class name from hCard is photo, but that doesn’t mean that a value of photograph is an error – it’s just not something we’re looking for.

To flag the above as an error would be like telling a Katheryn that she’s wrong and her name is really Catherine, simply because that’s the form of the name you’re expecting. It doesn’t add up, and it’s never good to piss off a Kate.

Validators (and Kates) aside, the other type of tool that exists in the programming world for checking code is what’s known as a lint tool. The subtle difference here is that a lint tool looks through your source code and highlights things that might be bugs or might cause problems. A bit like some of the popular accessibility checking tools, really. The principal being that it’s not easy to tell for sure if there’s a problem (or going to be a problem), but you can look for patterns that indicate a problem might arise.

I thought it’d be useful to take this idea and apply it to microformats. The result is rel-lint – a bookmarklet tool for checking values assigned to the rel attribute of links. This is where XFN values live, as well as tags, rel-license and so on. The tool checks any rel values against a known list and flags any not recognised. This doesn’t mean they’re wrong, just that they need checking. I’ve found it useful to have living in my bookmark bar for the last few weeks, and whilst it’s still only beta quality (there are bugs) I’d urge you to give it a try.

Turns out no one can spell ‘colleague’. Who knew?