First of all, thanks for the comments Paul! Both these and the feedback on XOXO are excellent.
On 12/21/05 3:24 PM, "Paul Bryson" <[EMAIL PROTECTED]> wrote: > http://microformats.org/wiki/hcard > > Is the hCard format supposed to contain all classes as specified in the > vCard RFC unless otherwise specified? Yes. It does contain all classes as properties specified in the vCard RFC. If you find something missing, please let us know! > Key is mentioned specifically in the spec, but there doesn't seem to be any > definition indicating how exactly it should be implemented. What kind of > key to use? Is there a link to a file or base64 encoded inline? Any such questions about "what kind of key to use" are left to the RFC. hCard doesn't change the semantic of the key property. > Is class="hcard" ever used? No. Though it has been suggested that should hCard ever expand beyond vCard, we could use class="hcard" to indicate such an expansion. Hopefully we would be smart enough to keep it backward compatible with hCard "1.0" as it were, and thus use something like class="vcard hcard", permitting hCard 1.0 parsers to consume such future content. Again, these are just "forward looking statements" and are not commitments to an expansion. We may just consider hCard "done" with the current 1.0 version. > The spec does not specifically address the use of handles or usernames, so I > was wondering about input about this. You may use nickname for that purpose. If the handle/username has a specific context/domain, then a URL to the profile of that username within it's service context/domain can be used. > There are a number of websites that will allow a user to have both a > username and to enter their real name. Many of these sites do not display > the real name to normal users, or possibly in normal browsing. It would > seem to make sense to display the username in the "fn" so that you have: > > <span class="fn nickname">Atamido</span> Yes. > Now, if an admin is looking at the same profile information, it would be far > easier on the backend design to have it simply add the real name before the > user name like this: > > <span class="fn">Paul Bryson</span> > <span class="fn nickname">Atamido</span> > > Would this be appropriate? Well, it wouldn't be valid per the hCard spec since you may only have one "fn" per hCard. However, due to the hCard parsing rules for unique (one instance only) properties, a compliant hCard parser encountering the two span fn elements above would use the first "fn", and ignore the second. In addition, due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion (maybe in old email? maybe in private email between Brian Suda and myself before the microformats lists were created?) about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback. E.g. right now a parser first looks for an "n" element. And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec. PROPOSAL: We should consider adding one more step and that is: If no "fn" is present either, then look for a "nickname" element to uses to imply both the "fn", and the "given-name", leaving the "family-name" as empty. This would allow you to write in your example: <span class="nickname">Atamido</span> For the "public" display and have it work and have it imply an "fn" and "n/given-name". Then in the admin case you would have: <span class="fn">Paul Bryson</span> <span class="nickname">Atamido</span> And it would use the "fn" to imply the "n", and everything would work as before for that case. The net result is that the admin sees more info than the public. Proposal captured here: http://microformats.org/wiki/hcard-brainstorming#Implied_.22FN_and_N.22_Opti mization_.28proposal.29 What do folks think? Tantek _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
