[uf-discuss] Microformats, WebApps 1.0 and UI widgets in browsers

[Karl Dubost]

Hi Ben,

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  
found.

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.

*would*

> 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 ***