Markup for addresses in HTML

This document discusses different ways of presenting address information, such as a postal address, in HTML documents. The basic pros and cons of the different approaches can be summarized as follows:

My recommendation is: For the document author’s address, use an address element and <br> between the components. For other addresses, use a div element with a class attribute, and wrap each component inside an inner div element. But if you would like to format the address as a box that has a background or a border and has just the minimum width needed for its content, consider using a table.

What is “address information”?

In this document, “address information” refers to contact information that is divided into small parts, which are normally presented as lines. This often means a postal address that typically consists of a name, street address, city, and country, perhaps with additional information. Telephone numbers, E-mail addresses, and Web page address are often included, too.

The components of an address can be characterized as fields of a record, and they could have names like “Name”, “Streen address”, etc. However, the names are usually not mentioned, except in fill-out forms.

Usually each component of an address is short enough to be presented on one line even if the available horizontal space is fairly narrow. If division into lines is necessary, it would be desirable to indicate that this has happened, in order to make the structure of an address clear. Thus, it would not be quite suitable to divide a street address into two lines so that they look like two components of the address:

Instead, if the rendering needs to be narrowed, it would be better to present the address as follows:

This can be achieved by using a style sheet like the following (assuming that each component is a div element inside an outer element that has class="address"):

 
.address div { margin-left: 1em;
               text-indent: -1em; }

Here text-indent sets the indentation of the first line (in the rendering of the component) to -1em, which nullifies the effect of the left margin. For other lines, the left margin is visible, i.e. they look like indented.

The desirable features of rendering an address can be described as follows:

• The address as a whole should constitute an element, so that it can be conveniently styled, by setting e.g. margins, background color, font, or a border.
• The element should have a width that is determined by the width requirements of its content, so that it is just as wide as needed. (This is relevant when you wish to use e.g. a distinctive background or a border.)
• Each component, too, should constitute an element, although this is relevant less often.
• Each component should appear on a single line of its own if possible. If word wrapping is necessary, the second line should be indicated as a continuation line.

Using the address element

It seems very natural to use the address element for an address. But according to the definition of the address element (in the HTML specification), the element contains contact information for the author of the document where it appears, or the author of a part of the document.

In any case, the address element behaves as a block with no implied division into lines. That is, even if you write each component of the address on one line, browsers are free to reformat it the same way as paragraphs, and they actually do so. Thus, you would still need to separate the components by br tags, as explained in the next section. (You cannot use div elements inside an address element, by HTML syntax.)

In theory at least, someone who is specifically looking for contact information about documents might have a user style sheet that strongly highlights address elements, or a robot that specifically searches for them. Of course, since address element is not very widely used for its defined purpose, and since it is sometimes used incorrectly for addresses in general, such methods are not highly successful, but perhaps not completely pointless either.

A further complication is caused by the fact that Internet Explorer displays address elements in italics by default. The following is how your current browser renders an address element:

Using italics is fairly pointless and not a common practice for addresses in general. However, it might be tolerable for a single address, which to be used as contact information. On the other hand, that this feature can be switched off easily in CSS, using just
address { font-style: normal; }
and it is still true that after IE 3 (where the best part of CSS support was that it was easy to switch it off), it has been impossible to turn off CSS support on IE using any normal methods. But it might still happen that your page is viewed on IE without your style sheet. (Scenario 1: You use an external style sheet, as authors normally should. The user saves your document using “Save HTML only”, later views it locally.)

Thus, by using address for addresses in general, against the specification, you don’t achieve anything in practice. In fact, using it by the specification is somewhat awkward too, since you are limited to inline content, which seriously limits the markup alternatives.

Using br between lines

The simple way to cause a line break in HTML is the br element. That’s what you would need to use e.g. when you put your own address inside an address element:

<address>
Jukka K. Korpela<br>
Päivänsäteenkuja 4 asunto 1<br>
02210 Espoo
</address>

You can also use <br> when you use some other markup than address to enclose the address, or when you don’t use any such markup.

Note that <br> causes a line break but does not prevent a browser from using other line breaks as well, to make the text fit within the available horizontal space. You would need to use other methods for that. In particular, you could use white-space: nowrap in CSS. This note applies to other methods discussed here, too, except the pre method.

Using div elements

By putting an address inside a div element, you just make it a block, without really saying anything about its meaning. Making it a block can be useful since it forces the address to start on a new line and to end in a newline, in the sense that subsequent text also starts on a new line even if nothing else causes a line break. But the div element as such does not create any vertical spacing (top or bottom margin).

For styling purposes, you normally need to assign a class to the div, since div elements are used for so many purposes in HTML authoring.

You would still need to take care of line breaks inside address, in order to divide it into components visually. You could use <br> tags as explained above, but you could alternatively make each component an inner div element e.g. as follows:

<div class="address">
  <div>Jukka K. Korpela</div>
  <div>Päivänsäteenkuja 4 asunto 1</div>
  <div>02210 Espoo</div>
</div>

This would be rendered as follows, assuming a suitable style sheet:

By using the method of nested div elements, you make each component of the address an element. This means that CSS rules can be assigned to components and that the components are accessible as nodes in the document tree (via the Document Object Model, DOM) in client-side scripting. To be honest, it needs to be added that the practical impact of such flexibility is relatively small, but it can become rather important in specialized applications. For example, advanced browsers that support CSS 2 would let you write a style sheet that presents, say, the second component of address in a desired way (using a selector like div.address > div:first-child + div).

Using a paragraph, p

Rather often, people use paragraph markup for addresses. This would mean that you use the previously described br method to cause line breaks but you would wrap the entire address between tags like <p class="address"> and </p>. Note that you cannot use div markup inside a paragraph, since a paragraph must not contain block elements, by HTML syntax.

It’s not quite logical to regard an address as a paragraph. Rather, a paragraph is a unit of text, typically consisting of a few sentences, expressing an idea or course of events. In good non-fiction prose, a paragraph typically starts with a key sentence that presents the basic idea, and subsequent sentences elaborate on that, present exceptions, etc.

In principle, this approach differs from the div approach by using illogical markup instead of semantically empty markup. On the practical side, however, using a p markup could help, if you have several addresses in a sequence. In non-CSS presentation, there’s no separation between the addresses, whereas p markup would imply some top and bottom margins for the elements in almost all visual rendering. The following table illustrates this; it contains two consecutive addresses presented in two different ways.

Using preformatted text, pre

To present an address as preformatted text, you simply write each component on a line of its own and slap the tags <pre> and </pre> around it. You could assign a style to the element, e.g. <pre class="address">, to make it easier to style such an address as a whole without affecting other pre you might use.

Thus, no markup is needed for line division, since by definition the source line structure is preserved. This, on the other hand, means that the lines do not constitute an element and cannot be styled separately. You could solve this problem by making each line a span element, since such markup is allowed inside a pre element. But then you don’t really gain much as compared with the method of div elements, and you lose some of its benefits.

The default rendering of pre elements uses a monospace font. Example:

Jukka K. Korpela
Päivänsäteenkuja 4 asunto 1
02210 Espoo

The default font size for such a monospace is often smaller than the overall font size (the copy text font size). The effect can be tolerable and even suitable for many monospace fonts, but it may become a problem if you change the font to something else. This can easily be fixed (if desired) in CSS by setting pre { font-size: 100%; }.

Although HTML specifications say that authors should not use style sheets to change the font to other than monospace, it is safe to do so as long as you remember that you can ultimately just suggest a font, not control it. In theory you could say pre { font-family: inherit; } in order to make the font same as elsewhere on the page, but IE does not support the inherit keyword. This means that to achieve such rendering, you would explicitly set the font the same as for the body element, e.g. body, pre { font-family: Arial, sans-serif; }.

The following example shows an address, presented as a pre element, styled the same way as addresses on this page in general.

Jukka K. Korpela
Päivänsäteenkuja 4 asunto 1
02210 Espoo

You can use inline (text level) markup inside a pre element, with some restrictions. For example, a elements are allowed, so you can use links. The prohibited inline markup elements are: applet, basefont, big, font, img, object, small, sub, sup. The general idea is that you shouldn’t use markup that may change font size inside the preformatted text. On the other hand, violating this rule just means (in addition to making the markup formally invalid) that the text will not stay exactly as preformatted. But you might not care about that if your only reason for using pre was to present an address as divided into lines.

There is however one potentially relevant practical flaw in using a pre element. By its definition, browsers do not wrap lines inside it even if wrapping would be needed to keep the text within some width. What happens then when lines overflow the available or specified width is a complex story, but it’s a problem anyway. On IE, the problem might not always be visible, since IE incorrectly expands an element’s width if the content does not fit horizontally. There are various workarounds to the problem, but none of them is particularly tempting. The following artificial example, with the element’s width set to smaller than needed, and with overflowset to scroll in CSS, illustrates the problem.

Jukka K. Korpela
Päivänsäteenkuja 4 asunto 1
02210 Espoo

Empty lines are significant inside pre elements. Thus you can create spacing between consecutive pre elements, even in non-CSS rendering, simply by using empty lines. On the other hand, this is not needed, since pre elements generally have default top and bottom margins corresponding to one line.

Using an unordered list, ul

Since an address can be regarded as a sequence of components, it could also be written as an unordered list. You would write each component as an li element:

<ul class="address">
  <li>Jukka K. Korpela</li>
  <li>Päivänsäteenkuja 4 asunto 1</li>
  <li>02210 Espoo</li>
</ul>

However, this means that the rendering has bullets by default:

• Jukka K. Korpela
• Päivänsäteenkuja 4 asunto 1
• 02210 Espoo

In order to remove the bullets, you would use list-style-type: none for the list in a style sheet. This would not remove the default left margin or padding, which would need to be handled separately, if desired.

Since ul has top and bottom margin by default, consecutive addresses would be separated from each other even when CSS is not used. But without CSS the appearance would not be address-like.

Using a table

There's yet another option for presenting an address in markup: a table. After all, the address consists of logical units (typically rendered each on one line), which might have headers attached to them, such as “Name”, “Street address”, etc. It looks pretty much like a data table, with the headers as th cells, actual data in td cells, and perhaps with a caption that says what the address is for, or something. Now if you omit the caption and imply the headers, does it stop being a table?

This means markup like the following:

<table class="address">
<tr><td>Jukka K. Korpela</td></tr>
<tr><td>Päivänsäteenkuja 4 asunto 1</td></tr>
<tr><td>02210 Espoo</td></tr>
</table>

In a table, each component of the address would appear as an element, a tr element. In addition to this, a table offers some interesting possibilities:

• You can draw a border around the address using just HTML.
• You can also use cellspacing and cellpadding properties to affect the rendering.
• Most importantly, a table automatically takes the natural width as dictated by its content. This makes this approach the most flexible when you wish to format the address as a box that has just the necessary width.

In the other approaches, the width of an address block would have to be set using some unit. In theory, you could use CSS features that set the width to the minimum needed, but this works poorly in current browsers. Naturally, if you have several addresses and you would like to present them as equal-width boxes, you could choose some specific width that you expect to be sufficient (preferably using the em unit).

The final example is an address, marked up as a table and formatted in CSS so that it has a background color and a border and its width is automatically the minimum width needed: