These are externally raised issues about hCard with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek
See related hCalendar issues.
- 2005-06-30 raised by Jack L. Wolfgang II
Please feel free to move these to the FAQs if they are better suited there.
- Handling middle names and suffixes: How does one handle middle initials/names in the hCard format and suffixes that are not honorific suffixes (e.g. Jr., Sr., II, III, etc. as opposed to Ph.D., Esq., M.D., etc.)?
A: By Brian Suda hCard is based of the RFC2426 spec. I you want to use a middle initial it can be expanded using the abbr element. <abbr title="Middle Name" class="additional-names">M</abbr>. Honorific Suffixes in the RFC include Jr. Esq. and other inherited suffixes, so i would just use <abbr title="Junior" class="honorific-suffixes">Jr.</abbr>
- Handling different types of addresses: How does one handle the TYPE (e.g. postal, work, etc.) speficiation for addresses as specified in RFC 2426 Section 3.2.1?
A: By Brian Suda If you want to add a type to certain elements, including address and telephone it will be done in the following manner:
<span class="adr"> <span class="work"> ... </span> </span>
<span class="tel"><span class="work">123.456.7890</span></span>
the TYPE needs to be a sub-element of the property (adr, tel, etc) NOTE: EMAIL does NOT have many TYPE attributes, only INTERNET and X400
- 2005-06-21 raised by Hixie
- Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCards must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
Please use this format:
- YYYY-MM-DD raised by AUTHORNAME
- Issue 1: Here is the first issue I have.
- Issue 2: Here is the second issue I have.