This mark-up snippit came across the mailing list a few days ago, i just wanted to point out a few parsing issues that people MIGHT not have been aware of.
There's no reason why you couldn't do this and infer a relationship: <div class="vcard"> <h2 class="fn org">Foo Co.</h2> <h3>Member Listing</h3> <ul class="xoxo"> <li class="vcard"><a href="http://mulettesgalore.com"; class="fn url" rev="founder moderator member">Joe Bob</a></li> </ul> </div>
In this example there is an hCard inside another hCard. The deapest class="vcard" (the second instance) will pull the following fields: FN: Joe Bob URL: http://mulettesgalore.com This is expected and makes sense. The outermost hCard (the first instance) will probably pull more than expected. FN: Foo Co. ORG: Foo Co. URL: http://mulettesgalore.com Because a parse finds the FIRST class="vcard" it will then attempt to look at ANY child element for additional properties. It finds the first FN and ORG == to "Foo Co." and uses that - it will also find "Joe Bob" but because it will ONLY take the first instance, we are safe here - so ORDER DOES MATTER!!! It will then continue to look through the list of properies and it will find that URL does match the criteria and also pull that. We all sort of assume that the URL is part of Joe Bob's vCard, but according to the parsing rules Foo Co. will find this. This is not a bug, it is a feature. When we begin to nest hCards in hCalendars, they BOTH have a URL property, this is shared so a URL inside a vCard which is inside a vEvent will be pulled for that EVENT, which might not be what is intended. Just wanted to make folks aware that "scoping" could be a misunderstood issue. -brian -- brian suda http://suda.co.uk _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
