Markup for Postal Addresses

Markup for postal addresses

The address element must only be used if this postal address represents the contact information for "its nearest article or body element ancestor", which, of course, is not the case for all addresses. But if address is used or not, it doesn’t affect the following.

The whole address should be enclosed in a p element, because "an address is also a paragraph".

As addresses should not be translated, the translate attribute should be set to no.

Each line (except the last one) should be followed by a br element, because the line breaks are meaningful (or "part of the content", as the HTML5 spec calls it) in addresses.

Each address part (name, street, city, etc.) can be enclosed in a span element. This is not required, but allows the use of semantic annotations.

Abbreviated address parts can be expanded with the abbr element, which can be useful for users not familiar with the address format (e.g., "What means MA?").

So up to this point, we have:

<p translate="no">
  W3C/MIT<br>
  32 Vassar Street<br>
  Room 32-G515<br>
  Cambridge, <abbr title="Massachusetts">MA</abbr> 02139 USA
</p>

Vocabularies

Schema.org’s PostalAddress type can be used for all address parts except for the room.

The vCard Ontology (which maps vCard to RDF) defines an Address class. There doesn’t seem to be a way to specify the room.

Another Address class is defined in the ISA Programme Location Core Vocabulary. The room can be specified with the locatorName property.

Microformats has h-card (with its p-adr) and h-adr. The room can be specified with p-extended-address.

Using the schema.org vocabulary with RDFa (Lite) as an example:

<p translate="no" typeof="schema:PostalAddress">
  <span property="schema:name">W3C/MIT</span><br>
  <span property="schema:streetAddress">32 Vassar Street</span><br>
  Room 32-G515<br>
  <span property="schema:addressLocality">Cambridge</span>, <abbr title="Massachusetts" property="schema:addressRegion">MA</abbr> <span property="schema:postalCode">02139</span> <abbr property="schema:addressCountry">USA</abbr>
</p>

Markup for an Email Signature or Postal Address in Markdown

The Markdown Syntax Rules simply state:

When you do want to insert a <br /> break tag using Markdown, you end a line with two or more spaces, then type return.

For illustrative purposes, the following example has all spaces replaced by middle dots (·):

First·Lastname··
Some·Company··
2041·Smile·Rd··
New·York,·NY··
(999)·999-8888

Which results in the following HTML:

<p>First Lastname <br />
Some Company <br />
2041 Smile Rd <br />
New York, NY <br />
(999) 999-8888</p>

And displays as:

First Lastname

Some Company

2041 Smile Rd

New York, NY

(999) 999-8888

Don't use address for address

The basic markup for postal addresses is a p element with br elements for separating the lines.

The address element conveys additional information, namely, that this postal address is (part of) the contact information for an article (if there is one) or the body (if there is no parent article).

So in both cases you should have the same markup for postal addresses, either with or without address container (depending on the purpose of the postal address).

In your specific example (company address in the footer of the company’s website), you should use the address element, because your company is the relevant contact for the webpage. Note that this address could also contain your company’s email address, telephone number etc.

Why the element is named `address` instead of `contacts`?

Probably because the element name was adopted from previous non-HTML specifications (and maybe its purpose/meaning was redefined at some point discussing HTML).

On Early History of HTML it says in the "Pre-1990: GMLguide and GML" section that the "Waterloo SCRIPT GML User's Guide" (some kind of predecessor to SGML) from 1988 mentions several tags that are now used in HTML, too, and among them is ADDRESS.

But it doesn’t really matter. While descriptive element names are helpful, they are not required. The semantics are defined by the HTML specification, not by the element names.

Looking at the various HTML versions, we can see that it was never intended to be used for every kind of postal address:

address in HTML5.1 (draft): "contact information"
address in HTML5: "contact information"
address in HTML 4.01: "contact information"
address in HTML 4.0: "contact information"
address in HTML 3.2: "authorship and contact details"
address in HTML 3.0 (draft): "address, signature and authorship"
address in HTML 2.0: "address, signature and authorship"
address in the first HTML draft: "address information, signatures, etc"

HTML: semantically mark up an address?

Well, if it's a list of businesses and their addresses, perhaps you should use a list. There isn't a semantic element for every possible thing you could do in HTML, you just have to use the one that is most relevant. Depending on how you're going to be formatting this information, you should use either a table if the data is in a tabular format, or a list for pretty much any other format.

You can style the list to remove the bullets at the side, but the bottom line is you're still providing a list of data, and that's the most semantic thing you could use.

Common Markup Language for Address/Location

You didn't mention XML.

Any reason why that won't fit the bill? Excellent support in the standard library.

Can you use plain text for addresses in schema.org markup?

Yes, you may use text as value for address. While its expected value is another item (namely PostalAddress) instead of text, Schema.org does not require this (bold emphasis mine):

While we would like all the markup we get to follow the schema, in practice, we expect a lot of data that does not. We expect schema.org properties to be used with new types. We also expect that often, where we expect a property value of type Person, Place, Organization or some other subClassOf Thing, we will get a text string. In the spirit of "some data is better than none", we will accept this markup and do the best we can.

However, it’s questionable if it’s really the "physical address" of an Organization if you only specify city and state.

If you would use a PostalAddress item as value, you could specify exactly what the address parts are that you provide, so consumers have a better chance to understand your data:

<p itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
  <span itemprop="addressLocality">Some city</span>, 
  <span itemprop="addressRegion">WY</span>
</p>

(Terminology: You are using the syntax, or format, Microdata and the vocabulary Schema.org.)

Semantic markup for address using Microformats

You might want to have a look at http://schema.org/. They have a different approach that is supported by major search engines. Also there are links to various testing tools to make sure you get the format right.

Markup for Postal Addresses