[wp-hackers] Any chance of the "Kubrick vs hReview" patch being
accepted prior to WP 2.0 release?
pp at myelin.co.nz
Tue Dec 20 23:27:56 GMT 2005
>> BTW, I've also been talking to David Janes about getting hAtom
>> (http://microformats.org/wiki/hatom) support into WP 2.0. This would
>> require renaming the "entry" and "content" classes in Kubrick, as
>> hAtom uses "entry" to wrap a post, and "content" to wrap the post
>> content/description. I can do a patch for this if this is an
>> acceptable sort of change...?
> I'm curious where these microformat guys get off absconding with
> fairly standard class names for use in their microformats.
> "decription"? "entry"? "content"? They seem pretty common to many
> I'm not thoroughly versed in the use of microformats, but it seems
> this could lead to a lot of false positives in a search. If someone
> pointed a microformat scanner at a default Kubrick blog, for example,
> it might come back with false positives.
> So educate me- What does the microformat syntax provide to prevent
> this from happening? After all, my use of "description" as a CSS
> class name predates any microformat.
Usually the more specific classes (which always have VERY common names)
have to occur inside a container with a less common name. In hAtom's
case, the outer class name is "feed", which is less common.
(It's "hreview" for hReview, "vevent" for hCalendar, etc.)
So a minimal page marked up with hAtom might look like:
<div class="entry" id="id of entry">
<h3><a href="url of entry" rel="bookmark">title goes here</a></h3>
<div class="content">entry contents go in here</div>
And a minimal hReview would be:
<p class="item fn">Name of thing being reviewed</p>
<div class="description">Review goes here</div>
The problems arise when you try to mark up existing HTML with
microformats, because the microformat authors always choose such generic
names ("item", "description", "content", "entry", etc)....
More information about the wp-hackers