[uf-discuss] hListing and hReview
brian.suda at gmail.com
Mon Jun 4 08:12:10 PDT 2007
On 6/4/07, Taylor Cowan <taylor_cowan at yahoo.com> wrote:
> hReview and the proposed hListing are very similar, sharing structure and properties. They both use "item" and it seems logical that they should work exactly the same in that area...but they are just different enough to cause parsing issues. From the hReview page, it states that "fn" must be a child....
> Encapsulated microformats (e.g. hCard and hCalendar events for now) may be set on the item itself (e.g. class="item vcard"). However, when using item info subproperties ("fn", "url", "photo"), they MUST be nested inside the item element.
> However, on the hListing proposal, item and fn are used in an example like this:
> <span class="item fn">Parking space</span>
--- this is a problem and it should be implemented in the same way
that hReview is, FN is a child of ITEM.
> If we can make them agree it sure is easier to write pasers, in this case you merely take an exising hReview parser and add/change a few property names. Since there are already public examples of that on edgeio I wonder if the restriction in hReview should be relaxed regarding ("fn", "url", "photo") as child nodes. It also seems that a second identifier within the same @class attribute is really a child anyway.
--- in the class attribute, the order of properties is not important,
so you can't say that it will always be the second identifer. The ITEM
property acts as a container that then has additional metadata such as
FN, TYPE, PHOTO, etc.
hListing should be updated to reflect this.
More information about the microformats-discuss