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
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
