hcard-user-interface
hCard User Interface
This page is for techniques and issues surrounding user-interfaces to author, publish, and display hCards.
Authors
Contributors
- ...
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:
- 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.