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 ***
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
