[uf-discuss] Microformats, WebApps 1.0 and UI widgets in browsers
karl at w3.org
Thu Feb 1 18:28:00 PST 2007
Le 2 févr. 2007 à 00:32, Ben Ward a écrit :
> On 1 Feb 2007, at 15:09, Karl Dubost wrote:
>> hCalendar: "description", "summary", "category", "location",
>> "status", "last-modified"
>> hCard: "adr", "street-address", "email", "geo", etc.
>> and plenty others.
>> You seem to have missed the bit where I was saying that any
>> mechanisms for switching being a specific class surrounding class
>> names, a profile URI attribute, etc would be fine.
> I'm not sure I see the problem here. Those class names are indeed
> generic and used all over the web, but they should only trigger
> user interface enhancements when they are children of ‘vcard’,
> ‘vevent’, ‘hatom’, ‘hatom’ elements.
> UI would surely only respond to valid and complete microformats on
> a page, not the sub-parts of them.
should and would.
I'm stressing this out now. As Mozilla was collecting requirements. I
think it should be said in an implementation guide to not only
trigger actions if and only if the appropriate *root* class names are
It is something very similar to the well known location issue,
squatting values :)
> Again, unless I've missed something in the above, that isn't
> necessary as those title and author class names are children of an
> appropriate microformat parent element, so would be ignored by a
> microformats parser.
> Please could you elaborate if I've misunderstood the implications
> of your concern.
I hope it helped to understand.
Again nothing against it, I think it's cool if it's well done.
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
QA Weblog - http://www.w3.org/QA/
*** Be Strict To Be Cool ***
More information about the microformats-discuss