Thanks for adding this bit of clarification -- I agree that his article is misguided and makes a number of assumptions that seem to come from no where. Criticism is certainly welcome and a healthy part of any debate, but did Uche even consult with folks from the community before writing this piece?
Microformats also are not a be-all, end-all, but they certainly are useful in the meantime. I can't see many reasons *not* to use them... add them to your templates once and be done with it, what's the big deal? As you suggested, getting data out there in as many parseable formats is a good idea -- might as well make those webpages you're already publishing just a bit more semantic.
I love the irony that, in spite of his distate for microformats, a simple hcard on that article would have made it pretty easy for me to add him to my address book and some hAtom formatting on the article would have made it subscribable in case he makes any changes. A missed opportunity at best, completely missing the point at worst.
I agree with your conclusion that The point about microformats and data-in-HTML is that it’s to get to places where the standard approaches don’t reach.
But I don't think Uche would actually disagree with that either. The point of his article wasn't that microformats are bad per se, but that they are a compromise - and when you embed one structure within an other, the result is necessarily more verbose and complex.
What I think is interesting is where that extra complexity (or 'dual context') can actually have value to the consumer of the data - for example, with Live clipboard (or Ben Nowack's Live Clipboard).
However I don't think Uche is missing the point by pointing out that putting data in html comes at a cost to the consumer (more complicated markup, and the machine-readable/human-readable mismatch demonstrated by the abbr[@title] pattern for dates).
There's nothing wrong with saying that the disadvantages should be weighed in the balance, rather than drowned out by a mantra of 'just use microformats/eRDF/RDFa'.
2007-05-20EDT13:00:52+00:00
#
But I don't think Uche would actually disagree with that either. The point of his article wasn't that microformats are bad per se, but that they are a compromise - and when you embed one structure within an other, the result is necessarily more verbose and complex.
What I think is interesting is where that extra complexity (or 'dual context') can actually have value to the consumer of the data - for example, with Live clipboard (or Ben Nowack's Live Clipboard).
However I don't think Uche is missing the point by pointing out that putting data in html comes at a cost to the consumer (more complicated markup, and the machine-readable/human-readable mismatch demonstrated by the abbr[@title] pattern for dates).
There's nothing wrong with saying that the disadvantages should be weighed in the balance, rather than drowned out by a mantra of 'just use microformats/eRDF/RDFa'.
I think microformats hedges it's bets a bit too much on search engines and user agents accepting and acknowledging the patterns. The principle concept behind microformats which is the standardization of "grammar" (markup) for communicating common data sets is however extremely important and useful. I'm open to any approach that makes more of our code semantic and makes digestion of content online more trivial. But I don't think that XHTML can go it alone.
2007-05-20EDT22:12:22+00:00
#
