h-card

From Microformats Wiki
Revision as of 07:47, 31 July 2016 by Tarmizi (talk | contribs) (tarmizi)
Jump to navigation Jump to search

<entry-title>h-card</entry-title> Tantek Çelik (Editor)


h-card is a simple, open format for publishing people and organisations on the web. h-card is one of several open microformat draft standards suitable for embedding data in HTML/HTML5.

h-card is the microformats2 update to hCard 1.0.

Per CC0, to the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 2020-10-22, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0.

tarmizi

<a class="h-card" href="http://microformats.org/wiki/Tarmizi">tarmizi </a>
{
  "items": [
    {
      "type": [
        "h-card"
      ],
      "properties": {
        "name": [
          "tarmizi"
        ],
        "url": [
          "http://microformats.org/wiki/Tarmizi.com"
        ]
      }
    }
  ]
}
<p class="h-card">
  <img class="u-photo" src="http://microformats.org/photo.png" alt="" />
  <a class="p-name u-url" href="http://microformats.org">tarmizi</a>

== Properties ==
h-card properties, inside an element with class '''h-card''':
* '''<code>p-name</code>''' - The full/formatted name of the person or organisation
* '''<code>p-honorific-prefix</code>''' - e.g. Mrs., Mr. or Dr.
* '''<code>p-given-name</code>''' - given (often first) name
* '''<code>p-additional-name</code>''' - other/middle name
* '''<code>p-family-name</code>''' - family (often last) name
* '''<code>p-sort-string</code>''' - string to sort by
* '''<code>p-honorific-suffix</code>''' - e.g. Ph.D, Esq.
* '''<code>p-nickname</code>''' - nickname/alias/handle
* '''<code>u-email</code>''' - email address
* '''<code>u-logo</code>''' - a logo representing the person or organisation
* '''<code>u-photo</code>'''
* '''<code>u-url</code>''' - home page
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical URL
* '''<code>p-category</code>''' - category/tag
* '''<code>p-adr</code>''' - postal address, optionally embed an [[h-adr]] {{main|h-adr}}
* '''<code>p-post-office-box</code>'''
* '''<code>p-extended-address</code>''' - apartment/suite/room name/number if any
* '''<code>p-street-address</code>''' - street number + name
* '''<code>p-locality</code>''' - city/town/village
* '''<code>p-region</code>''' - state/county/province
* '''<code>p-postal-code</code>''' - postal code, e.g. US ZIP
* '''<code>p-country-name</code>''' - country name
* '''<code>p-label</code>'''
* '''<code>p-geo</code>''' or '''<code>u-geo</code>''', optionally embed an [[h-geo]] {{main|h-geo}}
* '''<code>p-latitude</code>''' - decimal latitude
* '''<code>p-longitude</code>''' - decimal longitude
* '''<code>p-altitude</code>''' - decimal altitude
* '''<code>p-tel</code>''' - telephone number
* '''<code>p-note</code>''' - additional notes
* '''<code>dt-bday</code>''' - birth date
* '''<code>u-key</code>''' - cryptographic public key e.g. SSH or GPG
* '''<code>p-org</code>''' - affiliated organization, optionally embed an [[h-card]]
* '''<code>p-job-title</code>''' - job title, previously 'title' in [[hCard]], disambiguated.
* '''<code>p-role</code>''' - description of role 
* '''<code>u-impp</code>''' per RFC4770, new in vCard4 (RFC 6350)
* '''<code>p-sex</code>''' - biological sex, new in vCard4 (RFC 6350)
* '''<code>p-gender-identity</code>''' - gender identity, new in vCard4 (RFC 6350)
* '''<code>dt-anniversary</code>'''

All properties are optional.

== Status ==
'''h-card''' is a microformats.org draft specification. Public discussion on h-card takes place on [[h-card-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-card is ready to use and implemented in the wild, but for backwards compatibility you should also mark up top-level h-cards as classic [[hCard]]s.

== Property Details ==
(stub, to be expanded)

=== p-adr ===
<code>p-adr</code> can optionally embed an [[h-adr]] to cluster associated structured address properties. E.g. adding "p-adr" to the example earlier:

<source lang=html4strict>
<div class="h-card">
  <p class="p-name">Joe Bloggs</p>
  <p class="p-adr h-adr">
    <span class="p-street-address">17 Austerstræti</span>
    <span class="p-locality">Reykjavík</span>
    <span class="p-country-name">Iceland</span>
  </p>
</div>

Q: Why would you use "p-adr" to cluster associated structured address properties?

A: Because if you have more than one structured address, it helps to cluster which properties go with which address, e.g. home vs. work.

p-tel

Note: use of 'value' within 'p-tel' should be automatically handled by the support of the Value Class Pattern. And for now, the former hCard 1.0 'type' subproperty of 'tel' is dropped/ignored. If there is demonstrable documented need for additional tel types (e.g. fax), we can introduce new flat properties as needed (e.g. p-tel-fax).

dt-bday

Using truncated representations of dates for birth date is often good practice as noted in the vcard spec eg

  • 1985-04 for April 1985
  • 1985 for the year 1985
  • --04-12 for April 12th with no specified year

Reserved properties

Reserved properties (not used much, if at all, in practice):

  • p-organization-name
  • p-organization-unit
  • p-tz - timezone offset, e.g. <data class="p-tz" value="-0800">PST</data>
  • dt-rev

Examples in the wild

Real world in the wild examples:

offline

  • spreadly marks up share permalink pages with minimal h-cards inside h-entry

Validating

Main article: microformats validators

Test and validate microformats2 markup in general with:

Backward Compatibility

Publisher Compatibility

For backward compatibility, you may wish to use classic hCard 1.0 classnames in addition to the more future-proof h-card properties, for example:

<p class="h-card vcard">
  <span class="p-name fn">Joe Bloggs</span>,
  <span class="p-org org">Awesome Nonprofit</span>
  ...
</p>

The class vcard is a backward compatible root class name that indicates the presence of an hCard 1.0.

fn, org, and all the other backward compatibility hCard property class names are listed below.

Parser Compatibility

Microformats parsers SHOULD detect classic properties only if a classic root class name is found and parse them as microformats2 properties.

If an "h-card" is found, don't look for a "vcard" on the same element.

Compat. root class name: vcard
Properties: (parsed as p- plain text unless otherwise specified)

  • fn - parse as p-name
  • honorific-prefix
  • given-name
  • additional-name
  • family-name
  • honorific-suffix
  • nickname
  • email - parse as u-
  • logo - parse as u-
  • photo - parse as u-
  • url - parse as u-
  • uid - parse as u-
  • category
  • adr - parse as p-adr h-adr including compat root class adr
  • extended-address
  • street-address
  • locality
  • region
  • postal-code
  • country-name
  • label
  • geo - parse as p-geo h-geo including compat root class geo
  • latitude
  • longitude
  • tel
  • note
  • bday - parse as dt-
  • key - parse as u-
  • org
  • organization-name
  • organization-unit
  • title - parse as p-job-title
  • role

Reserved: (backward compat properties that parsers MAY implement, if they do, they MUST implement in this way:

  • tz
  • rev - parse as dt-

Background

This work is based on the existing hCard 1.0 and vCard specifications specifications.

Design Principles

(stub, expand)

Additions

We've tried very hard with h-card to stay compatible with vCard4, and thus additions should be proposed on the vCard4 mailing list.

However, you may still use this wiki to capture additions for h-card here:

See Also