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
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
One suggested 'best-guess' algorithm might be:
- If the name is one word, attempt implied nickname optimization
- If the name is two words, attempt implied n optimization
- For three or more words
- Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
- 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.