[uf-discuss] LinkedIn and Microformats

Tue Jun 13 15:44:26 PDT 2006

On Jun 13, 2006, at 5:10 PM, Tantek Çelik wrote:

>> Ideally, they'd be using microformats, but they're not doing anything
>> wrong here.  Microformats don't own class attributes, and that's a
>> perfectly descriptive use of the class attribute.  I think this is a
>> good reminder that those of us writing parsers shouldn't be assuming
>> valid microformat data based only on class attributes.  At the very
>> least, the above hcard doesn't have any N property, so parsers
>> shouldn't be treating it as parse-able data.
>
> Actually, I see less harm in treating Linkedin's use of  
> class="vcard" as an
> error and ignoring it than making a lot of extra work for every  
> implementer
> for one degenerate case.

But it's not just one degenerate case.  It's every degenerate case.   
This is just the most obvious case of an invalid hcard.  Any hcard  
invalid in ways that make it impossible to parse (e.g. missing FN,  
unclosed tags, etc.) has the same problem.  Unparseable hcards with  
class="vcard" show up on this list regularly.  Isn't it safe to  
assume they show up in the wild even more often?

> But even without that, it is not unreasonable to assume that  
> class="vcard"
> is an hCard.
>
> Just as it is not unreasonable (as in they all do it) for a browser to
> assume that <html> is an HTML document even if there is no DOCTYPE  
> that
> points to a DTD URL which defines the element <html> as such.

It's not unreasonable for a browser to assume anything with a .jpg  
extension is a JPEG, but I'm glad my browser checks for valid data  
before presenting it to me.  It's just bad user interface to suggest  
something can be parsed when it can't.  Parsers are able to parse the  
data already.  It's not any extra work to do this before indicating  
the data is parse-able.  I'm not suggesting this should be part of  
any spec, but I don't see any advantage to making the assumption that  
everything with class="vcard" is a valid hcard.  And I say that  
having written parsers that make this very assumption.

Peace,
Scott