Last week in Boston we were discussing Pingerati and "how do you find microformats" (in general). One passing idea I had was that search engines should supply a CSS element selector. So for example, to find Tantek's hCard we could search "tantek css:vcard". Neatly, this shows one of the great benefits of microformats -- by working in HTML data world, we gain the benefits of existing tools but still work with data.
Opting for a solution that requires changes on the search engine side (eg, crawling CSS files) might not be the best path, IMHO. It means relying on search engines on several points: 1. Motivation - while by definition everyone reading this is interested in Microformats, I don't know how many people working on search engines are even aware of MFs. 2. Implementation - once the motivation is there, you're relying on different search engines to implement the standard correctly and completely. (Admittedly, it won't be hard to implement. But big companies occasionally like to put their own spin on standards...) 3. Sharing - above reasons by nature will limit the number of engines which will support the MF search. This increases the vulnerability of MF-search based apps to moves like Google's recent SOAP API deprecation. In any case, if we're already asking publishers to modify their output, I think it would be more likely to catch on if it provides instant results, by working with existing search engines. Cheers, Nir _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
