[uf-discuss] Custom Fields Microformat?
Stephen Paul Weber
singpolyma at gmail.com
Sat Nov 25 10:35:12 PST 2006
Creating 80%-or-more overlapping formats is evil. XOXO can be made to
do anything - and this most especially. So you have to change the
output code a tad more to apply it than you do for some other formats
- what does that hurt? The resulting code is much better structured
On 11/25/06, Aaron Gustafson <aaron at easy-designs.net> wrote:
> Manuel Simoni wrote:
> > Cool, I think it's isomorphous... The "p-v" corresponds to
> > "hcustomfield", the "property" to "hcustomfield-name" and the "value"
> > to "hcustomfield-value".
> Exactly, like I said, we were trying to keep it simple.
> >> I don't know if you think what we've put together would be applicable
> >> (we were trying to keep it as simple as possible, hence the short
> >> names), but I agree this is something that would be really nice to
> >> have and should be an aspect of microformats, possibly existing as a
> >> microformat unto itself which can be combined with other ones
> >> when/where it makes sense to create subformats specific to a
> >> particular use (for instance, wine, televisions, cars, etc. all have
> >> custom fields in the product world, most of which are consistent
> >> within their category and could combine a property-value construct
> >> with a standard hProduct to make a nice subformat -- perhaps a better
> >> approach than the creation of niche microformats like
> > hWine, though I'm open to argument in the other direction).
> > This sounds very interesting... of course, there's a danger
> > here of going meta, and never coming back :)
> Yes, but I don't necessarily see that as a bad thing. As long as the
> microformat is helping people do what they need to do, I think it's all good
> and it could certainly keep the formal microformats at a bit higher level
> (while still allowing for extensibility). It could create a thriving
> subformat ecosystem, which I think is pretty neat.
> > As an aside, I find this use of automatically inferring
> > "property" and "value" inside a <DL>  problematic, because
> > it places a non-necessary burden on parsers, while making the
> > life of writers only minimally easier.
> > 
> > http://microformats.org/wiki/hproduct-brainstorming#List_prope
> I'm not convinced of that. It is not all that difficult to parse a DL, in
> fact I just recently wrote a generic JS row-striping script that allows you
> to stripe tables and lists of all types (including DLs, even with multiple
> DTs or DDs per group, as per the spec) . The code was only a few lines
> and could easily be repurposed to allow for harvesting of property-value
> pairs. It simply requires node walking as opposed to bulk collection. It's
> just an alternate sub-routine for collection based on the nodeName of the
> "p-v" CLASSified element.
>  http://easy-designs.net/code/stripey/test.php
> Also, I was reminded (by Tantek) that we need to be focused on writers more
> than parsers, and I think that from that standpoint, in the (edge) case
> where you need multiple values for a property/a single value for multiple
> properties/etc., DL makes a lot of sense -- much moreso than duplicating the
> p-v structure or embedding a UL inside the value. Consider it a DRY KISS
>  http://en.wikipedia.org/wiki/DRY
>  http://en.wikipedia.org/wiki/KISS_principle
> > Let's keep the topic of a general name/value subformat on the
> > table, and see how it develops.
> Agreed. I think this is really great stuff and could do a lot to allow for
> extensibility in microformats.
> Aaron Gustafson
> Easy! Designs, LLC
> microformats-discuss mailing list
> microformats-discuss at microformats.org
- Stephen Paul Weber, Amateur Writer
MSN/GTalk/Jabber: singpolyma at gmail.com
More information about the microformats-discuss