Martin McEvoy wrote:
semantically on their own the above does not mean much nothing at all
really, search engines, parsers, things that index dates and times,
would have to peek at the parent to find out what the actual values
are
for.
But that's true already of any instance of the value class name.
Parsers and spiders already have to perform look-ahead searches for
any elements with a class of "value" wherever they come across any
microformat class names (summary, location, fn ...everything basically).
http://microformats.org/wiki/value-excerption-pattern
http://microformats.org/wiki/hcard-parsing#class_value_handling
I should probably add links to those pages from:
http://microformats.org/wiki/parsing-microformats
http://microformats.org/wiki/parsing
Anyway, my point is that search engines and spiders already need to
perform this look ahead if they are extracting microformats. If they
are just searching for dates and times, then you're right, the class
name "value" by itself doesn't say much (although the presence of
hyphens or colons says everything) but I'm not aware of any spiders
that are indexing datetime information outside of the context of events.
I don't think the above suggestions are anything ground breaking or
new
just a natural expansion of the current design pattern.
I think that, where possible, we should avoid thinking up new class
names. Sometimes it's unavoidable but in this case, we can reuse an
existing pattern.
Bye,
Jeremy
--
Jeremy Keith
a d a c t i o
http://adactio.com/
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
