From Microformats Wiki
Revision as of 22:03, 8 July 2006 by DrewMcLellan (talk | contribs) (New page, first draft)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

hCard User Interface

This page is for techniques and issues surrounding interfaces to author, publish, and display hCards.



  • ...

Single Input Field for Names

When capturing name data that is later to be presented as a hCard, it's important that the data is collected at the highest fidelity possible. As not all names are suitable for hCard's implied-n optimisation (and therefore can't be output as fn, with n omitted), capturing component parts of the name individually enables the proper construction on n when generating the hCard.

Sometimes, however, constraints require a name be collected with a single field. Once such example is common blog CMSs (WordPress, TextPattern) that use a single database field to store the name against each post comment. In such cases it is always desirable to find a way to collect the name with higher fidelity. However, if this simply cannot be done, the implementer could chose to attempt to best-guess the component parts of the name to form a valid n.

One suggested 'best-guess' algorithm might be:

  1. If the name is one word, attempt implied nickname optimization
  2. If the name is two words, attempt implied n optimization
  3. For three or more words
    1. Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
    2. Apply the grammar "(honorific-prefix) given-name additional-name(s) family-name (honorific-suffix)"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorise an ambiguous name component than to generate an invalid hCard.