>
HTML >
The problem with microformats

7 September, 08:46 pm

I really like the idea of Microformats. Lots of people seem to like the idea of Microformats, the idea goes something like this:

  1. A schema is specified—mostly by defining class names—that defines the way to us HTML to markup the information used in common situations; things like contact details, ratings, and product details.
  2. Web developers use these schemas to markup the information on their websites.
  3. Search engines and other data aggregators that know about these schemas search for the micorformats embedded in pages and can then parse the information as if it was XML (ie. they know exactly what the purpose of each peice of information is).

Ok, so my degree in Fine Art hardly qualifies me to talk about information, but this has obvious (if you’re involved in web development) advantages; it would mean that sharing information between websites would be very much easier and more reliable. It would be great to be able to use Microformats to present the information in the sites I build to the wider internet with the knowledge that the information I put in them can be umambiguously interpreted—it would be better for everyone, convenient for me, easier for search engines, and the clients and the public would benefit from greater accuracy.

So why isn’t everyone using them? To put it simply; they’re too bloody complicated. I’m busy, I’m working on projects on short deadlines—and I’m sure this is the case for most front-end developers—I don’t have time to wade through wads of hypothesising specifications. I don’t have time to work out if the subtleties of the specification allows me to use the HTML I want or present the information in the way my clients want. I mean read this:

vCard’s NAME, PROFILE, SOURCE, PRODID, VERSION properties are defined in Sections 2.1.2, 2.1.3, 2.1.4, 3.6.3, 3.6.9 of RFC 2426. Content publishers MUST NOT use these properties in their hCards, and as such, hCard consumers/parsers MUST IGNORE these properties if they are found within an hCard. Instead. hCard to vCard converters SHOULD use the title of the page where the hCard is found (e.g. the <title> element in (X)HTML documents) to construct the NAME property, MAY output a PROFILE value of “VCARD” per RFC 2426, SHOULD use the URL of the page where the hCard is found to construct the SOURCE property (e.g. perhaps as a parameter to a URL/service that converts hCards to vCards), for an output vCard stream (e.g. a .vcf file). Only services/applications that output actual vCards should write the PRODID property, with the product identifier for said service/application. Similarly, only such services/applications should write the VERSION property, with the value “3.0” (without quotes) per RFC 2426 Section 3.6.9.

Still here? Good, but I bet you didn’t read all that – I certainly didn’t. And how does the next sentance make you feel?:

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

We’re talk about HTML here people! It’s hardly the European Consitution… The last time I read something like that it was the incomprehensible lawyer-speak lease agreement when I was buying our flat. It smacks of being written by people who want to be the only ones to understand it; a protectionist club. If I could understand the lease agreement I wouldn’t need to pay a solicitor, if I could understand the hCard specification would I think Tantek was so special?

If microformats are going to take off, then the people behind them must realise that they are making a product for people like me to cunsume. If Microformats are going to be used in commercial websites, not just semi-professional wannabe standardista blogs, then they need to be not only easy for me to use, they need to be packaged in a way that is quick for me to understand. I’m not going to explain to a client that they spent the best part of my daily rate while I trawlled through a swamp of petty psuedo-legalese to understand an obscure technique that is of very questionable financial benefit to them.

I’m not interested in hypothetical semantic nuances (well… I could be, but not if I’ve got a deadline), I want solutions that work and save me time.

I have tried to implement Microformats (hLising and hProduct) in the ecommerce site we’re building at the moment, but I’m still confused by the details of how exactly they should be implemented. In the end I stripped both formats back to their minimum required elements and left it at that, who knows what will come of it…

(And lets not even mention the <abbr> tag.)

Comments:

  1. Jack Kelly replied on Nov 6, 02:21 pm : #

    Oooh, u-formats. I’m with Tim Berners-Lee and you… the “semantic web” will be the shizzle… if anyone can be bothered to implement it.

    Incidentally, I think one interpretation of your post is that charging by the hour is bad for creativity.

    Damn clients ;-)

    What we need is a functioning communist economic system… ahem…

  2. Ed Everett replied on Nov 6, 03:02 pm : #

    one interpretation of your post is that charging by the hour is bad for creativity

    Duh! Pay artists by the hour and you’ll have graphic designers.

    But I think in this case it’s more about bad documentation and implementation being bad for a niche clique of web-developers.

    The easier way than communism to get rid of clients is to make products — then you’ll just have customers…

Comments closed for this article.

**************** notes test