The Problem with Microformats: No Pope of Rendering…?

Robert Brook’s playing around with the Textpattern microformat plugin highlights my number one frustration with microformats: I’m never quite sure if I’ve done done my microformatting right.

View-Source Coding

When doing View-Source style coding (XHTML, CSS, microformats, XSLT, and web-world JavaScript) you need at least one baseline to test your code in. In “normal” programming, you have the complier to tell if your code is invalid. In the View-Source model, you have the browser and your eye-balls: if you change the web page, hit re-load, and it the result doesn’t match your expectations, then it’s time to fix the “bug.”

That kind of model requires that the community come up with a consensus for a baseline. In the web, the baseline was lynx and Mosiac at first; then Netscape; then IE 6; now it’s FireFox. That is, if your web page worked in the baseline, then, for the most part, anything you saw out of the ordinary in other browsers was considered the fault of the browser, not your [X]HTML/CSS.

The Microformats Baseline

In the world of microformats, I haven’t found that baseline yet. Back in March when I played around with hCard, I settled on Metonymie.com’s hCard extract (thanks!). But, having run my hCard (in the sidebar of my blog, PeopleOverProcess.com) through several hCard aware applications and pages since, I get different results each time.

For example, here are several examples of how my hCard is rendered today:

Metonymie.com’s hCard extract

TextPattern Plugin (from what Robert says)

Technorati Microformat Search

Tails for FireFox

All Different

As you can see, they’re each slighty different. I have no problem with each tool rendering each one differently if that’s what the tool authors want them to do. But, I would like a single, “maximal” microformats viewer to help me verify and play around with hCard and other microformats. I was hoping that the Technorati microformat search would do this, but either it doesn’t or I haven’t figured out the right place to click.

Playing Around with hReview

The primary reason I want such a service is to make it easier for me to play around with and learn microformats. For example, I tried to slip a mini-reveiw of a local poboy shop into a DrunkAndRetired.com post last week, but I wasn’t quite sure if I’d done ir right. Technorati takes a little while to suck in the hReview once you ping it, so I went off Tails, which looks like this:

Once crawled, Technorati renders it as:

(To be fair, Technorati also picked up the Gene’s hCard as Tails did, I just didn’t screenshot and include it above.)

What’s the Baseline?

So, my question is, in my continuing desire to learn and have fun with microformats, what’s the baseline, or baselines, I should use? I’d prefer to have some service I can give a URL to and see the “maximal” extraction (shows as many fields as possible) of the microformat, but I’ll settle on whatever’s available, works, and has community acceptance as the baseline.

Not Just Validity…

RSS and ATOM had a part of this problem — validity — forever before Feed Validator came in and saved the day. Now, when there’s some encoding problem in one of my RSS feeds, folks send me queries with FeedValidator to prove that my feeds are messed up. Once I change the RSS such that Feed Validator validates it, I’ve done all I can on my end, and it’s the feed consumer that needs attention.

I say that Feed Validator solved part of the problem, because the other part is showing me what my microformatting will render as: nothing sucks more than writing a bunch of code (or “code,” in this case), and then not being able to run it. And don’t get me wrong: as I tell people all the time, I’m not poo-poo’ing what exists, I’m just looking to find the even better version of present reality, whether that’s available right now or in the future, where we all shall live.

Technorati Tags: hcard, hreview, html, javascript, microformats, standards, technorati, viewsource