[uf-discuss] Microformat h-names contradict the process documentation

[Andriy Drozdyuk]

I thought so, but what about:
- Rel tags - they  could be used for something else - these is no way
to infer if the rel-tag is beign used in "semantic ways" or not.
- Other formats that don't have namespaces, e.g. geo
- "Design for humans first, machines second"

I mean, wouldn't one always go for either "all-must-use-namespaces"
(aka xml schemas!) or let's keep it as simple as possible?

Sorry - I am just trying to get a jist of where the ideas are coming
from in these standards, not trying to undermine them...
-Andriy Drozdyuk



On Mon, Mar 22, 2010 at 6:24 PM, Frances Berriman <fberriman at gmail.com> wrote:
> On 22 March 2010 20:38, Andriy Drozdyuk <drozzy at gmail.com> wrote:
>> I see the microformats in the upcoming drafts section all named:
>> hAtom, hAudio, hListing, hMedia, hNews, hProduct, hRecipe, hResume, hReview
>>
>> While in the actual documentation:
>> http://microformats.org/wiki/process
>>
>> one can find this philosophy:
>> "DO NOT start with even labeling your effort "hXYZ". This is a very
>> common mistake."
>>
>> What is the purpose of naming things with "h" prefixes and using all
>> kinds of abbreviations? (e.g. "adr" instead of "address").
>> It's already on the web (hence html) - shouldn't it be clear that it's (h)tml?
>>
>> I was just wandering if anyone else ever thought about it, or am I
>> just being silly, or missing something?
>> Thanks,
>
> Good question.
>
> It's more for the benefit of parsers.  It's a sort of simple
> name-spacing technique.  Imagine trying to look for recipe
> microformats in HTML - the class name "recipe" may be used for all
> sorts of correct reasons, but a microformat parser is specifically
> interested in the instance where it's going to retrieve the right kind
> of data. Looking for "hRecipe" is much easier.  Of course, you can
> infer whether the data is useful from it's child elements, but it's a
> quicker solution in many cases (and isn't the universal solution).
>
> I think the comment you quoted is a slightly different topic - It's
> just advice that step 1. of defining a new microformat is not naming
> it :)
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>