[uf-discuss] hCard Comments

[Tantek Ç elik]

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" <paul at msn.com> 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