SimpleQuiz › Part XVII: Addresses

It’s been quite a while since the last SimpleQuiz–but Dave Shea has ended the drought with a question on marking up addresses.

And I quote (essentially verbatim from Dave):

Snail mail addresses are a series of details, most of which require a physical break between each line. This is very much presentational, but important presentation to reflect even in the unstyled view. What is the best way to represent an address in this format:

ABC Widgets, Inc.
100 – 1234 West Main Street
Anytown, State
Zip
Ph: 555-555-1234
Fax: 555-555-1234


  1. <address>
      ABC Widgets, Inc.<br />
      100 - 1234 West Main Street<br />
      Anytown, State<br />
      Zip<br />
      Ph: 555-555-1234<br />
      Fax: 555-555-1234<br />
    </address>

  2. <div class="address">
      <p>ABC Widgets, Inc.</p>
      <p>100 - 1234 West Main Street</p>
      <p>Anytown, State</p>
      <p>Zip</p>
      <p>Ph: 555-555-1234</p>
      <p>Fax: 555-555-1234</p>
    </div>

  3. <dl class="address">
      <dt>ABC Widgets, Inc.</dt>
      <dd>100 - 1234 West Main Street</dd>
      <dd>Anytown, State</dd>
      <dd>Zip<dd>
      <dd>Ph: 555-555-1234</dd>
      <dd>Fax: 555-555-1234</dd>
    </dl>
  4. None of the above, or a combination of the above.

126 Comments

  1. I think I would use either an ordered or unordered list similiar to C but with an ordered list instead, then styled without the numbers.

  2. Jacob Patton says:

    D. What about a slight modification of C:

    <dl class="address">
      <dt>Address:</dt>
      <dd>ABC Widgets, Inc.</dd>
      <dd>100 - 1234 West Main Street</dd>
      <dd>Anytown, State</dd>
      <dd>Zip<dd>
      <dt>Ph:</dt>
      <dd>555-555-1234</dd>
      <dt>Fax:</dt>
      <dd>555-555-1234</dd>
    </dl>

    By adding “address”, “phone” and “fax” ids/classes to the dt, you can modify things even further through CSS–hiding the “address” dt completely, for example.

  3. JP says:

    Also, I’m talking about each adding hooks to each term element, individually, in the last sentence, of course.

  4. Personally, I’ve used example “C” in more than a couple projects over the last few months. It seems to me to be the most appropriate way to seal the deal.
    Jacob’s alternate example above is also good. Either could work depending on your needs.

  5. Dan Jallits says:

    I vote C. As the use of a definition list sllows me to add visual styling for the company or persons name, while maintaining the rest of the address in a simple “plain-text” format.
    Dan, it is good to see the SimpleQuiz back again.

  6. I’ve always gone with A. That is what the address element is for, marking up addresses. And br has not been deprecated, as this is precisely what it should be used for.
    Answers B and C add too much extraneous code, and remove the semantics of the address tag and place it in an attribute.
    The need for an unstyled version to be displayed with the line breaks is not a trivial thing. Part of the semantics of an element is some sense of presentation. Paragraphs are understood to be groups of sentences that are separate from each other in some way. The CSS can control how that separation is achieved, but the unstyled presentation still separates paragraphs from each other and other page elements.
    Address blocks also need to look a certain way, and that nearly always means line breaks. There has to be some way of indicating where those line breaks should be, and the br tag seems to make the most sense…

  7. Chris says:

    *sticks up hand* First timer alert!
    For a start, I didn’t even know an address tag existed. I’d fire up Dreamweaver and find out, but the computer’s going way too slow tonight.
    Presuming you are just looking for an unstyled address, I think secret option D is the best way to go about it.
    Option C does allow full customization, which is useful, but is pointless in the context, as you are after an unstyled address. Secondly, D works perfectly in old browser versions.
    Why present the Address as a bullet list for people without Stylesheet capabilities? Addresses aren’t presented this way, either on the web or in the real world. So why present it that way in this case?
    Finally, my idea significantly reduces the amount of code used, reducing page size (granted, only by a kb or two). But still, this is what you guys are after, isn’t it? :)
    Anyway, I know I have no chance of winning, but it feels good to finally reply to a post on here after admiring your work for months!

  8. Chris says:

    Appologies, my attempt at posting code didn’t work too well. I thought the point in the “code” tag was, it didn’t parse html.
    My idea was to use option (B) but replacing the P tags with br /’s

  9. Well. A would probably be the theoretical correct one, but as the example clearly points out it is far from powerful enough to get the job done.
    B is just strange
    C used to be my favorite. It might not be theoretical correct, but you can actually use it to solve your needs
    Jacob’s solution is even better. Not only does it provide added support – it would also scale to handle contact person and other important information.
    What I do today is use XML – and then use an XSL style sheet to create a variation of C and Jacob’s examples (server side).
    Like this:
    <address>
    <company>ABC Widgets, Inc.</company>
    <street>100 - 1234 West Main Street</street> <city>AnyTown</city>
    <state>State</state>
    <people>
      <person type="sales">John Doe</person>
      <person type="marketing">Jane Doe</person>
      <person type="support">Uncle Doe</person>
      ...
    </people>
    <communication>
      <phone>555-555-1234</phone>
      <fax>555-555-1234</fax>
      <mobile>555-555-1234</mobile>
      ...
    </communication>
    </address>

  10. Josh Heyer says:

    I agree with Mark Newhouse. Option A is my choice.
    I agree that the other methods offer more hooks but I tend to style each portion of the address the same for consistency.

  11. Hmm… funny. I used SimpleCode to create the <code> block, but it looks rather strange

  12. I’ll have to respectfully disagree with going for C just so that you can add visual styling for a company or person’s name. That is what strong & em are for.
    I’m not sure what Chris (#7) was trying for in his example – maybe using pre? In that case, I’d also make sure to wrap it in an address tag.

  13. Mike Rundle says:

    I love Jacob’s idea.
    Using CSS to display: none; the appropriate sections of the definition list is a great idea, and makes a whole lot of sense to me since it still preserves the nice semantic markup.

  14. Thomas – SimpleCode adds br tags, and then MT adds another line break automatically. I need to figure out a better way to filter stuff.

  15. Rob Mientjes says:

    ‘That is what strong & em are for.’
    That’s not true. They are used for emphasis and stronger emphasis. You should then actually use i and b.
    And address… It’s made for it. I guess A, because semantics must make sense, and address couldn’t make any more sense.

  16. web says:

    I believe if you are putting an address on a page using anything but the tag .. you are not being semantically correct.
    Sure you can claim that you are “defining” the address, but if an address tag exists, should we not use it?
    What about in conjunction with the css “white-space: pre” rule.
    That would insert your “precious” line returns.
    ;)

  17. Steve Smith says:

    I can’t go for B because each line is not a paragraph. I can’t go for C either because (and Dan I know agrees with me here) I can’t support a list with only one item (even if it has multiple definitions). My prefered method would be to mark it up exactly as Dan has marked it up in the question:
    <p>
      ABC Widgets, Inc.<br />
      100 - 1234 West Main Street<br />
      Anytown, State<br />
      Zip<br />
      Ph: 555-555-1234<br />
      Fax: 555-555-1234<br />
    </p>

    The <br /> here is not presentational, it is actually part of the content. It acts very similar to punctuation in this case. You don’t remove periods from a paragraph because they are not part of the “content”.

  18. Steve – I’ll save my opinion for later :-), but I’ll disagree on one point — that lists can’t contain one item.
    The W3C says:
    “All lists must contain one or more list elements”
    Just wanted to clarify that. It’s possible that lists contain one item, in fact I do this often. Especially for times when the list contains a single item today — but may expand into multiple items later.

  19. Pete Lasko says:

    A lot of people are going to want to go with C because of the hooks, but what you need to do is weigh the ability for extra hooks with need for them. Do you seriously need to be able to show and hide or style each individual line in an address? If you want to hide it, don’t write it in the first place.
    If you want to be semantic, fine, use the address tag. But a definition list? Maybe it would be better to keep that one around for definitions.

  20. Dave S. says:

    At Mark Newhouse:
    Answers B and C add too much extraneous code, and remove the semantics of the address tag and place it in an attribute.
    The reason I can’t accept without a debate that <address> is the appropriate element is because the spec is far from clear on whether the <address> element is virtual, physical, or both. The example certainly seems to suggest virtual, and unclear semantics are about as useful to me as no semantics.
    “I’ll have to respectfully disagree with going for C just so that you can add visual styling for a company or person’s name. That is what strong & em are for.”
    That’s more like what b & i are for, or CSS if you go that route. strong and em aren’t purely for visual styling, they’re for implying visual and non-visual emphasis to the text.
    At Jacob Patton:
    “By adding “address”, “phone” and “fax” ids/classes to the dt, you can modify things even further through CSS—hiding the “address” dt completely, for example.”
    This makes quite a bit of sense, though it’s on the heavy side. Beats a table!

  21. Nick says:

    Funny, I was just at a meeting where this very topic was discussed. At the time I opted for solution A, and in practice it’s what I do all the time.
    Right now I’m wondering about the semantics of using multiple address tags, each given an id or a class (depending on the needs of the page) further specifying the bit of the address represtented. These could, at the designer/developer’s discression each be wrapped in a container div. Perhaps something like:

    <div id="address">
      <address id="companyName">ABC Widgets, Inc.</address>
      <address id="street">100 - 1234 West Main Street</address>
      <address id="cityStateZip">Anytown, State</address>
      <address id="phoneNumber">Ph: 555-555-1234</address>
      <address id="faxNumber">Fax: 555-555-1234</address>
    </div>

    I suppose there are too many id’s in there for me to be comfortable with it as a workable “right” answer, but is there a good reason not to use multiple address tags?

  22. Brian Tully says:

    why not go with a modified version of A, which seems to be the most semantically sound approach. Instead of using br tags why not specify white-space: pre; for the address tag in your stylesheet?
    you could even add the following to style different parts of the address as needed:

    <address>
      <span class="name">ABC Widgets, Inc.</span>
      <span class="street">100 - 1234 West Main Street</span>
      <span class="citystate">Anytown, State</span>
      <span class="zip">Zip</span>
      <span class="phone">Ph: 555-555-1234</span>
      <span class="fax">Fax: 555-555-1234</span>
    </address>

    then in your stylesheet:
    address {
      white-space: pre;
    }
    address .name {
      font-weight: bold;
    }
    etc…

  23. Cory says:

    I’m split, as I so often am.
    On the one hand, I feel that address tag should be used for this, and I don’t like a one-item list.
    On the other hand, I don’t like forcing line breaks with br, but I very much like the semantics of the list.
    I’ll go for A.

  24. Miriam Frost says:

    While C is very tempting, I use A for all of the reasons Mark mentioned. If I really need to be able to change the style, it’s one of the very few places I use a span tag, and class it appropriately as phone, fax etc. Span and br aren’t deprecated; forcing an address into a dl would be the semantic equivalent of forcing it into a table.

  25. Will says:

    I’m partial to Jacob’s solution (in fact, I’ve used something similar on my own site), but I would probably wrap the <div> in an <address> tag as opposed to giving it the class="address" attribute. I’d have to double-check the specs, but I believe that the <address> tag is meant to be used in conjunction with nested block elements, like <blockquote>.

  26. Mike P. says:

    I’ve never liked what the specs have to say about the <address> element.
    Now that the wine-ing (sp?) is finished, I’ll throw my hat in for ‘A’, for the reasons outlined by Mark.
    The style-hook-monster in me does like Jacobs idea, but if I need to do something special I suppose a <span> and an appropriate attribute would do, combined with ‘A’.
    Does it work? Sure can. Is it semantic? Sure is :-)

  27. Jina says:

    A, for sure. I didn’t know it existed, but it sure makes sense.
    and now to go change my markup…

  28. Nick says:

    My only problem with the address+span solution is that the unstyled version won’t maintain the line breaks.
    Going a step further and adding an inline style to the address tag:

    <address style="white-space: pre;">

    … will only solve that problem in browsers fully supporting CSS 2.1, which most likely would have rendered a more complicated CSS file anyway.

  29. Steve Smith says:

    Sorry if I missunderstood you Dan. I was going off of your earlier conclusion from Quix XV in which you said:
    “While it may seem a bit weird to have a series of one-item lists – I’m never one to argue that a list can contain just one item.”
    While I do agree that if an area has the possibility for expansion working a list in there somewhere is a good idea, marking up a single address doesn’t seem like that situation. And perhaps I’m just too lazy to come up with an example. =}

  30. Malarkey says:

    Hi Dan :)
    Using address is a must. How about modifying A to,

    <address>
    <span>ABC Widgets, Inc. </span>
    <span>100-1234 West Main Street, </span>
    <span>Anytown, State, </span>
    <span>Zip, </span>
    <span>Phone: 555-555-1234 </span>
    <span>Fax: 555-555-1234 </span>
    </address>

    and using,
    address span {
    display : block;
    }
    It’s a bit ‘wordy’I know, but adding a comma and leaving a space before each closing leaves you open to ignore the spans in future CSS revisions, allowing the address to run into one line.
    Just playing devil’s advocate… ;)

  31. One thing I think that is very important about semantic code (for me) is that it must never imply visual style. The code must retain maximum flexibility so that you can display it anyway you need.
    Using A is for me no good. The BR tag is a visual tag. Using EM, STRONG, B or I is just as bad, because again they are added to create visuals.
    What if you do not want to emphasize the company name, and instead only emphasize the zip code? The you still need to rewrite every single address.
    B does not, in any way, provide meaning to your code. If you where a computer you would have no way to tell if it was an address, a recipe or part of the navigation. You do have the class=”address”, but it implies style (note: using id=”address” could also indicate data – but then you cannot have two addresses on a single page).
    C does provide some meaning (especially Jacob’s version), since you have the DT tag along with each definition.
    The best compromise would be to have

    <address>
    <dl>
    <dt>company</dt>
    <dd>Company name</dd>
    <dd>Street</dd>
    ....

    But the XHTML specs do not allow block elements inside an ADDRESS tag. So, since the only way to markup an address using <address> is to also include styling elements it is hardly semantic. Leaving us with no other choice than to make a hack.
    For me I get better control using C – but regardless if I use A,B or C (or D) it would always be a hack semantically speaking.
    Dan: Thanks for cleaning my initial reply!

  32. Jim Dabell says:

    None are correct.
    A is wrong, because the address element is for marking up the address of the person responsible for the page. Your post seems to indicate you want a method for marking up addresses in general.
    B is wrong as the individual lines of an address are not paragraphs. They are lines.
    C is wrong because you aren’t defining terms. The address in question is not the definition of the term “ABC Widgets, Inc.”.
    You should use a p element or a div element with br elements to separate the lines. Whether a paragraph is the correct structure for an address is debatable; if you don’t think it is, use a div element.

  33. Major says:

    It´s A.
    Unfortunately there is no “standard” for choosing the right elements and an order.
    I often saw formulas where i had to choose a “ZIP”. I don´t know what a “ZIP” is. I only know the zip in my jeans.

  34. Dan Delaney says:

    I like the idea of the tag. Unfortunately, the HTML spec states it’s purpose as:
    “Information on Author: The ADDRESS element may be used by authors to supply contact information for a document or a major part of a document such as a form.”
    So it’s stated purpose is strictly for identifying contact infomation for the author of the page–not for marking up just any address that happens to be on the page, as in a company directory page or some such.
    Even so, if Tim Berners-Lee wants our markup to be more semantic, this seems like the most logical tag to markup an address with.

  35. Option A really seems the most accurate. Adding spans in for styling specific elements is also completely valid. It’d be nice if you could put DIV tags inside an ADDRESS tag. Not sure why the W3C felt you shouldn’t be able to do it.

  36. Dan Delaney says:

    Hee hee–make that: “I like the idea of the ADDRESS tag.” :o(

  37. Dante says:

    A. B and C are daft and semantically incorrect.

  38. Steve – Ah, that should’ve been:
    “While it may seem a bit weird to have a series of one-item lists – I’m never one to argue that a list can’t contain just one item.”
    Oops :-) I was trying to say that I’m not opposed to single-item lists.

  39. Here’s a slightly modified option A (if we talk about markup purism here). At least that’s what I currently tend to use.

    <address>
     <a href="http://www.abcwidgets.com/">ABC Widgets, <abbr title="Incorporated">Inc.</abbr></a><br />
     100 - 1234 West Main Street<br />
     Anytown, State<br />
     Zip<br />
     Ph: <a href="tel:+1-555-555-1234">555-555-1234</a><br />
     Fax: <a href="fax:+1-555-555-1234">555-555-1234</a><br />
    </address>

    (I’m sure someday the tel: and fax: schemes are going to work.)
    Definition list are certainly not the choice: you could end marking everything up with them, e.g., instead of this:

    <h1>SimpleBits</h1>
    <p>…site content…</p>
    <p>…site content…</p>

    use this:

    <dl>
     <dt>Simplebits<dt>
     <dd>
      <p>…site content…</p>
      <p>…site content…</p>
     </dd>
    </dl>

    But that’s just weird. Breaks are by no means presentational in case of address. No doubt XHTML 2.0’s l (line) element is going to do the job better.
    I don’t think address is for page author only. A company on the whole is responsible for making a site available, so using address for its contact information is perfectly legal.

  40. I’ve never really even thought about another way of doing it, other than Option A. I can see the advantage of Option C (my favourite alternative), especially with the modification posted soon after, but I don’t know if it’s really necessary, given the additional markup.
    This brings up the issue of Ph. and Fax, though. First, shouldn’t they be marked as an abbreviation and acronym, respectively?
    And should phone and fax numbers really be in the address tag?

  41. waylman says:

    One of the first things that came to my mind was that while addresses are generaly displayed with the line breaks, they can also be displayed inline (perhaps in the body of a letter) with a comma seperating each line. So which solution would allow this?
    While I would lean toward A as it is the only one that uses <address> (which should be done in my mind) I also see the benefit of C or Jacob’s variation of it. The extra tags give more power to display as desired. However at the same time a list seems like overkill.
    For these reasons, I was impressed with Brian’s suggestion. It provides the flexability for styling and useses <address>. The only glaring problem is with CSS disabled or not supported (Lynx) we get a one-liner without even a space between each line. Maybe if the spans were replaced with divs.
    If we wanted to display it inline we still could with
    address div {
    display:inline;
    }

    and use :before or :after pseudo-elements to insert commas. I realize this could be done with lists as well, but not everyone likes lists. Using <br /> makes it impossable (as far as I know) to display inline. For this reason I’de have to go with D. Of course, if we could garentee it would never be displayed inline then A would suffice.

  42. I recently re-designed a web site which contains many addresses. What I have done might be completely incorrect (Damn it, Jim! I’m an architect not a web page designer!) but I did as others have noted here: added a white-space as “pre” tag in the style sheet. This has facilitated a relatively sppedy move from a spreadsheet of addresses to membership directories. example PS: Just received your book Dan. :-)

  43. Steve Smith says:

    Dan, thanks for the clarification. Your comment makes more sense to me now. Sorry for the confusion.

  44. Matthew Walsh says:

    I like option A. And Brian’s spans are a nice optional addition if you need more hooks for styling. But I think you really need the br elements for a decent fallback in non-css aware agents, unless you are going to use commas, like Malarkey suggested. But I think for maximum flexibility, with good degradation, Option A plus spans, and keeping the brs, works well.
    And if you ever wanted to display the address a single line, I’m not positive, but I belive you could use:

    address br {display: none;}

    Possibly adding generated commas, as waylman suggested.

  45. Yuda says:

    I go along with option A with one change: the zip code should be on the same line as the city and state.
    Addresses are one of a handful of situations where a line break is not presentational but instead part of the content. Oftentimes, a poem is another. In these instances I never hesitate to use the br tag.
    I’ve seen some references about the address tag being used for the page author only, but I’ve seen other “official” references that either suggest or explicitly state this is not the case.
    Ultimately, a fully xml solution is preferable, with tags for street address, apartment number, etc, etc, but line breaks will still have to be included for the sake of older user agents.

  46. Jim Dabell says:

    “I’ve seen some references about the address tag being used for the page author only, but I’ve seen other “official” references that either suggest or explicitly state this is not the case.”

    You can’t get more official than the specification. It doesn’t matter who disagrees with it, that’s what the spec says.

  47. Matthew Walsh says:

    The spec specifically says: “contact information for a document or a major part of a document” That doesn’t neccesarily imply only the page author. It could also be the company, a webmaster responsible for site maintenance, the author of an article on the page (could be multiple authors and/or articles), etc.
    However, it also certainly does not suggest so broad a scope as to be appropriate for just any general address. For example a directory with just adressses would usually not fit here. Although there is where the list solution (c) might be nice. Of course dl elements as prescribed by the spec are similarly ambiguous, but anyway…

  48. Michael Smith says:

    I feel I’d have to use the ADDRESS tag, rather than using a class attribute. So for me, either (A) or maybe an OL within an ADDRESS:
    <address>
    <ol>
    <li>ABC Widgets, Inc.</li>
    <li>100 – 1234 West Main Street</li>
    <li>Anytown, State</li>
    <li>Zip</li>
    <li>Ph: 555-555-1234</li>
    <li>Fax: 555-555-1234</li>
    </ol>
    </address>
    An address does feel like an ordered list of details to me.

  49. Darrel says:

    I prefer to use a giant animated GIF of a mailbox with a letter flying into it.

  50. Marcus says:

    ‘A’: that’s what it’s there for.

  51. Scott says:

    Lol Darrel.
    I would do the same as Chris (#7), choice b modified to use <br /> instead of <p>...</p>. I choose thise option because I haven’t moved up to your fancy XHTML and beyond just yet.   :)

  52. ACJ says:

    With HTML4/XHTML1 I’d go with a or, alternatively; <address><pre>...<pre><addess>.
    In XHTML2, we’ll have this nice element l, but that’s not ging to help us much now.

  53. ACJ says:

    *shrug*
    That should be: <address><pre>…</pre></address>.

  54. hemebond says:

    <dl>
    <dt>ABC Widgets, Inc.</dt>
    <dd>
    <address>
    100 - 1234 West Main Street<br/>
    Anytown, State<br/>
    Zip<br/>
    </address>
    </dd>
    <dt>Phone</dt>
    <dd>555-555-1234</dd>
    <dt>Fax</dt>
    <dd>555-555-1234</dd>
    </dl>

    What’s with the lack of indentation?

  55. James Z says:

    I would be inclined to say A. However, after having thought about it I say C.
    C provides a clear order to the phrasing of the address information while allowing any styling options that you may desire.
    An address may flow in a standard order, and the address tag may be intended for this. But it would be nearly impossible to style-ize (nicely) a plain address tag structured with tags.
    So for my meager vote, I say C.

  56. Paul Kilroy says:

    What about a custom schema? Shouldn’t we be eating our own dog food and pushing web standards?
    This exmaple works pretty well in firefox.
    <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN” “http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>
    <html xmlns:html=”http://www.w3.org/1999/xhtml” xmlns:postal=”http://www.foo.bar/postal”>
    <html:head>
    <style type=”text/css”>
    postal\:address postal\:city {
    display: inline;
    }
    postal\:address * {
    display: block;
    }
    postal\:city:after { content: “, ” }
    postal\:phone:before { content: “Ph: ” }
    </style>
    <html:title>Postal Address</html:title>
    </html:head>
    <html:body>
    <postal:address>
    <postal:name>ABC Widgets, Inc.</postal:name>
    <postal:streetaddress>100 – 1234 West Main Street</postal:streetaddress>
    <postal:city>Anytown</postal:city>
    <postal:state>State</postal:state>
    <postal:zip>Zip</postal:zip>
    <postal:phone>555-555-1234</postal:phone>
    </postal:address>
    </html:body>
    </html>

  57. James Z says:

    That should read:
    “structured with <br/> tags.”

  58. russ says:

    A is the correct answer period.

  59. Stephane says:

    The only solution that make sense to me is A. an address should be mark-up with and address tag. as someone already said, if you want to remove the BR just use :
    address br { display: none; }
    I’m not sure if it work’s in explorer but what else is new.

  60. bryan says:

    A) Can’t use because the <br /> is for line breaks, and we have an actual seperation of data types here. Something with greater specificity is needed.
    B) Well, it’s just silly to make a <div id="address"> when there is already an <address> tag. Then we have the whole mess with <p>…why are they marked up as paragraphs?
    C) It breaks the entire concept behind a definition list. When you define an address for a company, sure you have a similar weight behind a physical address, a phone/fax number, or a website. But the key to this exercise is to give full flexibility. A street name is not complete enough to have the same weight as a phone number, so giving it an equal weight using <dd> breaks the purpose of definition lists.
    D) Well, almost. waylman is the closest so far, but after weighing the pros and cons, I have a new suggestion (I apologize in advance for the lack of indention…):

    <div class="contact">
    <hn>ABC Widgets, Inc.</hn>
    <address class="physical">
    <div class="street">
    <span class="s_num">100 - 1234</span>
    <span class="s_name">West Main</span>
    <span class="s_type">Street</span>
    </div>
    <div class="region">
    <span class="city">Anytown</span>
    <span class="state">State</span>
    </div>
    <div class="post_code">Zip</div>
    </address>
    <address class="phone">
    <span class="area_code">555</span>
    <span class="exchange">555</span>
    <span class="number">1234</span>
    </address>
    <address class="fax">
    <span class="area_code">555</span>
    <span class="exchange">555</span>
    <span class="number">1234</span>
    </address>
    </div>

    1) It preserves the semantics of the <address> tag.
    2) It gives forward and backward compatibility.
    3) It gives complete control over each type of information.

  61. stylo~ says:

    >>Using A is for me no good. The BR tag is a visual tag.

    So is the P tag. Do you not use it either? ;-)

  62. Lachlan Hunt says:

    For A, If the address is for contact information for the author of the document, then it’s the best, however Address was not, unfortunately, designed for any arbitary address.
    For B, each line is not a seperate paragraph so it’s not quite right either. A combination of A and B would be better.

    ABC Widgets, Inc.
    100 – 1234 West Main Street
    Anytown, State
    Zip
    Ph: 555-555-1234
    Fax: 555-555-1234

    (or using from XHTML2 would be even better)
    For C, each line of the address is not a seperate definition of the term “ABC Widgets, Inc.”, so it’s wrong. C could be used if there were multiple addresses, where each address was marked up in a seperate , but each line of the addresses were broken with a .

  63. Lachlan Hunt says:

    Oops… That example was supposed to be:
    <p class=”address”>
    ABC Widgets, Inc.<br />
    100 – 1234 West Main Street<br />
    Anytown, State<br />
    Zip<br />
    Ph: 555-555-1234<br />
    Fax: 555-555-1234
    </p>
    (I forgot HTML was allowed, I assumed it the < and > would be converted automatically)

  64. The Wolf says:

    ‘A) Can’t use because the
    is for line breaks, and we have an actual seperation of data types here. Something with greater specificity is needed.’
    When you type an address into a word document, what does it insert after each line? Line breaks.
    There is no need for more seperation unless you really want to, but then you could always use span elements to do that if you need to.

  65. The Wolf says:

    ‘Using A is for me no good. The BR tag is a visual tag.’
    Ever tried to colour a br tag? ;)
    Actually, a visual tag is something that is displayed on the screen, as BR tags are not displayed, they are not visual. They are simply inline tags that are replaced with newline characters in the rendering engine.

  66. stylo~ says:

    #61 shows why most people ignore standards discussions. I suppose if you were required at some point to style an address and convey the meaning of it for an assortment of alien beings, it would be good, though, for true precision, you might consider a span around every single character, or better still a dedicated xml tag for each.
    Otherwise, solution A works quite well for human beings who want to know your address, or even for anyone writing a prog this century to collect addresses on a page and regex them into bits.

  67. The Wolf says:

    Hahaha! Lol @ stylo~ :D
    Thats a really good way to point out how useless #61 is. ;)

  68. stylo~ says:

    >>Actually, a visual tag is something that is displayed on the screen, as BR tags are not displayed, they are not visual.
    I know I can see them on the page when you use them ;-)
    Both BR and P are rendered in standard form as providing visual line breaks, which is the relevant issue here, no?

  69. Lea says:

    I would, and have, used A. However, I would take the phone numbers completely out and put it in its own paragraph–that’s not part of the address! Part of the contact information, but not the address.

  70. bryan says:

    Actually, Wolf, when you type an address into word, you put in the line breaks. A word processor doesn’t parse the data for you and decide line breaks are necessary, that’s something you figured might be good.

  71. The Wolf says:

    ‘Actually, Wolf, when you type an address into word, you put in the line breaks. A word processor doesn’t parse the data for you and decide line breaks are necessary, that’s something you figured might be good.’
    If you use the standard way of formatting a letter then you usually put in line breaks. But thats not my point, word processors don’t store the addresses as lists. Stop nit picking.

  72. Wolf,
    “‘Using A is for me no good. The BR tag is a visual tag.’
    Ever tried to color a BR tag? ;)”
    Well, I have – and I get the most fantastic translucent effect imaginable.
    Anyway, the BR tag is not about data – but how you want it presented visually. Using BR you indicate, in your code, that you want each part of the address separated by a line. By doing this you lock your address into a single presentational (visual) mode.
    What if you want the address written inline – say separated by a comma (as someone suggests) or in a tabular form (like a table of addresses). Then your nifty BR tag has to be rewritten – or worse yet, you need to overrule the tag in CSS.

  73. stylo~ says:

    I don’t want to be overly negative towards Bryan and number #61, but want to pick up further on my comment above and use #61 as a base.
    Three issues are often conflated in these discussions of html (where xml points are not relevant):
    1) Css style: adding extra tags to so many parts of the address is unnecessary and just bad coding, as there is no practical situation in which you would need to style differently the various parts within the phone number or street. At most, you might do the company name or such in bold and add a span or strong tag. No right answer, depends your needs and how portable you think something must be (vs. doing a simple code change if more is ever needed).
    2) Inherent browser style: how something displays with no css added, i.e., the base styling built-in to various browsers. #61 displays OK, though the company name is quite separate from the address because of hn tag margins.
    3) Semantics: in no way whatsoever is #61 of sematic value, or forward compatible with anything. No machine (or alien, if you will, as I said above) can figure out what a “physical” is or an “s_type.” A “state” can just as easily equal on/off as equal California, an “exchange” or a “region” many things, while a “number” doesn’t even nec mean numeric as it could contain “three.” Even if found within class=”contact” (what does that nec mean?) let alone an address tag, these descriptions are unuseable as not standards to be relied on.
    A machine is going to need someone to prog it to look for and understand (i.e., use) an “address” which means, as far as I can foresee, that it can only safely look for address tags or certain tags with class or id equal to address, then maybe cleverly attempt to regex the rest. But already the latter looks nasty until such time as there is a state, country, and phone number tag (inside or outside the address tag, as you will), which there won’t be.
    It seems any semantic discussion of web code has this base problem that is ignored from the beginning: anything other than a standardized and expressive tag (or far in the future, a standardized class or ID) is of extremely dubious semantic value to a machine. I don’t know that “expressive” is the correct term, but what I mean is that telling a machine that this here thing is a class of list doesn’t do it much good at all, while saying this thing is an address does. I should add the addition that humans can understand a document at a glance slightly better if they know this is a list and that a definition of a term and so forth, but what a machine would do with that general glance beyond taking the h1 to be important and a few other simple deductions, I don’t know. I don’t see how a machine can possibly decide that lists or DLs or paragraphs in themselves are of any different value from each other and then “use” them appropriately until such time that there are, as I said, standardized classes, IDs, and even DTs (“Address” not “Address:”, etc.). But XML will do that – maybe only within an organization -, not html where it can’t be too relevant due to billions of non-standard pages.
    In summa: an address as an address with breaks, as a list, as a paragraph with breaks, or as a div with a pre tag: what real, exact difference do you think it is going to make on the points of 1) css styling hooks, 2) inherent browser style, and 3) semantics. Is that not the real question, where 3 is of by far the least value in html for some time to come, if not always?
    I vote for A as a nice and simple data chunk that displays well with no css and can be styled via css to remove break tags and with spans added if needed. It is also very clearly defined for me and machines as an address. D is also good in an overt x=y way, but not good if you see a need to decipher an address from a tag and not a class.

  74. Krasimir says:

    The best way for represent: A. When the document is unstyled, the text looks like that:
    ABC Widgets, Inc.
    100 – 1234 West Main Street
    Anytown, State
    Zip
    Ph: 555-555-1234
    Fax: 555-555-1234
    When we add a style, the look can be the same but also can be different. So, I think that the best is A. Of course, there are so many ways to do that like

    ABC Widgets, Inc.
    100 - 1234 West Main Street
    Anytown, State
    Zip
    Ph: 555-555-1234
    Fax: 555-555-1234

  75. Krasimir says:

    My last words should be readed like that
    <p>ABC Widgets, Inc.<br />
    100 - 1234 West Main Street<br />
    Anytown, State<br />
    Zip<br />
    Ph: 555-555-1234<br />
    Fax: 555-555-1234</p>

  76. Rimantas says:

    A is out – as it was already stated, spec (HTML4.01) reads: “The ADDRESS element may be used by authors to supply contact information for a document or a major part of a document such as a form. This element often appears at the beginning or end of a document.”
    This does not prohibit using it for other purposes, but… There is something fishy.
    B is out — too presentational.
    C is OK – spec allows broader use of DLs: “Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words.”
    So I feel OK using DT for the company name and DD for the parts of address itself.

  77. Joranovski says:

    I tend to choose for option D and I would use the adress tag combined with an unordered list like this:

    <adress>
    <ul>
    <li class="name">ABC Widgets, Inc.</li>
    <li class="street">100 - 1234 West Main Street </li>
    <li class="citystate">Anytown, State</li>
    <li class="zipcode">Zip</li>
    <li class="phone">Ph: 555-555-1234</li>
    <li class="fax">Fax: 555-555-1234&lt/li>
    </ul>
    </adress>

    for the ul you can set the list-style-type to none, so the bullets won’t display
    Allthough the adress is always in the same order, I didn’t choose for an ordered list.
    So far my $0.02

  78. zedzdead says:

    D
    I’d create a line by line flash animation and embed it on the page….kidding!
    But with 77 previous replies I had to write something different didn’t I?

  79. Major says:

    I think we should skip directly to XML:
    <adress>
    <name>ABC Widgets, Inc.</name>
    <street>100 – 1234 West Main Street</street>
    <town>Anytown, State</town>
    <zip>Zip<zip>
    <tel>555-555-1234</tel>
    <fax>Fax: 555-555-1234</fax>
    </adress>
    I think it is the only semantically correct possibility.
    Including XML in XHTML shouldn

  80. David House says:

    I’d have to go with A. This is actually (debateable) a semantically correct usage of .

  81. Andy says:

    I don’t mean to start a war here guys, and I’m no expert like some of you, but if you read the spec again for ADDRESS the answer might be clearer:
    The ADDRESS element may be used by authors to supply contact information for a document or a major part of a document such as a form. This element often appears at the beginning or end of a document.”
    Some of you seem to have interpreted that to mean that you have to provide the contact information FOR the author of the page, when in fact it’s to allow the author to provide contact information for the document.
    Surely that’s not limited to just the person that built the page? The contact for the page may be the company that own the page/site or person that wrote the content originally
    So… in light of that I think that [A] is nearly the best solution, simply because it’s exactly what ADDRESS is designed for. (I would however put the phone and fax numbers in a list outside the address tag more like the style of [C])

  82. David says:

    “The [address] tag defines the start of an address. You should use it to define addresses, signatures, or authorships of documents.”
    [A] is the only alternative that makes sence. Address lines are not paragraphs, neither are they a part of a list. They are address lines and should be wrapped in an [address] tag and separated with the semanticly correct (in this case) [br] tags.

  83. Jim Dabell says:

    “I think we should skip directly to XML”
    All that means is that no program besides programs you write understand what your new element types mean.
    “Surely that’s not limited to just the person that built the page? The contact for the page may be the company that own the page/site or person that wrote the content originally”
    Well no, but generally speaking, the organisation is who you consider to be the author.
    “So… in light of that I think that [A] is nearly the best solution, simply because it’s exactly what ADDRESS is designed for.”
    Hang on a sec, you’ve leaped from “contact address for the document” to “addresses in general”. That’s not what the spec says.
    For example, if a company provides a page with a list of addresses for their regional branches, then it’s still the wrong element type to use. Those regional branches aren’t addresses for somebody responsible for the document.

  84. Hi Dan,
    for me it’s A, because I looks “right” for me, and unstyled it also looks good.
    Greetings
    Rene

  85. Egor Kloos says:

    I’d just use [a].
    Why? [b] doesn’t give my anything in terms of meaning it just gives me extra code. [c] is an option. But in balance does the extra code give me more meaning that option [a]. No, not really. Jacobs solution is a solution when the information is considered so important that martians must understand what going on or the design requires special treament. Personally I’ve never done it that, but in some cases I think I might need to. So thx Jacob.
    In the end for most cases I would more than likely still go for [a]. KISS.

  86. Small Paul says:

    Yay, another Simplequiz! Many thanks Dan.
    The <address> tag is one of the few places in HTML where we’ve got a tag that’s useful for a real-world issue: providing contact details for the ‘document’ (for which I think we can also read ‘web site’). Seems a shame to neglect it. (Imagine if we had a <navigation> element, but still used lists.)
    Like Alexander, I’m also not sure how keen I am on using definition lists for this example. I understand the idea of using them to demonstrate a relationship between two things, but I’m not sure how useful it really is. I also think it’s easy to dig the idea because of the styling opportunities it presents, which means the styling tail is wagging the content dog just a little.
    Heading tags are also meant to indicate structure, I think (the WAI guidelines say so, no idea about the HTML spec). So we could go…
    <h3>Address</h3>
    <address>
    ABC Widgets, Inc.<br />
    100 – 1234 West Main Street<br />
    Anytown, State<br />
    Zip
    </address>
    <h3>Ph:</h3>
    <address>555-555-1234</address>
    <h3>Fax:</h3>
    <address>555-555-1234</address>
    …and do the formatting with styles. Not sure what the ramifications of multiple address tags are for future use of this information. It validates, in any case.
    I disagree that the line breaks aren’t semantic here. You glean something about the meaning of an address from its line breaks: if something is on the next line, it means it’s a new part of the address, e.g. the district name, not the street name any more. A bit like a poem: a new line can be important to the meaning there too.
    I do agree they’re less semantic than a nice XML-based solution, or improved HTML would be. But it’s easy to forget that HTML is a pretty blunt tool for most semantic work (which is kinda the point of this quiz).
    (Gosh, that was long.)

  87. John Pull says:

    C, with the addition of classes for the individual fields of data.
    Why? ‘Cos at some point I might be required to write an alternate stylesheet for manipulating the field data, and in a worst case scenario:
    - the source data (likely XML) may not be available;
    - dynamically-created content may not be possible.

  88. David Duret says:

    Once I used something like that (similar to A):
    <address>
        <span>ABC Widgets, Inc</span>
        <span>100 - 1234 West Main Street</span>
        <span>Anytown, State</span>
        <span>Zip</span>
        <span>Ph: 555-555-1234</span>
        <span>Fax: 555-555-1234</span>
    </address>

    The <span> let me more possibilities due to the “display” property. One could display each line “inline” (address.span { display:inline; }) or as a “block” (address.span { display:block; }).
    Adding a class or an id to each <span> let us display that address with more flexibility:
    <address>
        <span class="name">ABC Widgets, Inc</span>
        <span class="street">100 - 1234 West Main Street</span>
        <span class="city">Anytown, State</span>
        <span class="zip">Zip</span>
        <span class="phone">Ph: 555-555-1234</span>
        <span class="fax">Fax: 555-555-1234</span>
    </address>

  89. pete says:

    curious: is this a situation begging for the use of xhtml 2′s “l” tag or does that seem like just another option to everybody?
    in the meantime, though, i vote for a.

  90. Ove Klykken says:

    I still see no strong argument why you should not use A. Why would you not use the semantic tag created specifically for this kind of information?

  91. Okay, originally I said A but after re-reading the spec I may have to change my mind.
    The spec says “may be used by authors to supply contact information for document”. My first thought was MAY doesn’t mean “HAVE TO”. Thus opening the door to other usage.
    But we should think of the INTENTION of the W3C when they formed the spec. They obviously intended it as a way of marking a paragraph or block of text as contact information in the form of an e-mail address. The XHTML2 spec adds the href property right to the address tag. How is marking a snail mail address with the tag going to help forward-compatibility?
    And no browser is going to come out now to handle the HTML4.01/XHTML1 spec any differently than it’s handled now. So, new browsers aren’t going to treat the address tag any differently.
    The HTML spec provides little in the way of semantics and it should be a given that there is little hope of giving it meaning except through the users ability to figure out what an address is.
    Option B or C will work just fine.

  92. I like A.
    It is easily styled, the tag makes sense, it degrades nicely, and it can be machine read. I don’t se the line breaks as a problem since they are more or less mandated by the postal service to be part of the address. In this case they are not presentational, they are part of the content!
    I like the unordered list idea, since an address is essentially a list of various information that can be used to contact someone. Putting it inside an address tag, however, would not be valid markup. Address is an inline element, but lists are block elements. You run into the same problem with paragraphs or divs.

  93. Phil Balchin says:

    Although i like the idea of using inline XML, via a new namespace, this might not work in all brwosers as expected. So, i’ll go for option E. Instead of using just one address element, i’ll use one for each peice of data

    <div class="ContactInfo">
    <p>Please Send Post to:</p>
    <address class="name">ABC Widgets, Inc</address>
    <address class="street">100 - 1234 West Main Street</address>
    <address class="city">Anytown, State</address>
    <address class="zip">ZIPCODE</address>
    <address class="Country">Mercia</address>
    <p>or get us the phone:</p>
    <address class="phone">0885 589658</address>
    <address class="fax">0519265 92981</address>
    <address class="email">me@who.com</address>
    </div>

    That way, each address element can have styles applied to it, each address element doesn’t contain again block elements. This method also allows for text to be inserted between address elements, without breaking structure. So although the user doesn’t need to know what markup is used, any screen readers or search bots will be able to identify only address data.
    That said, being more programmer based, i’ll like to see the XML examples win, only problem is current support for this is patchy.

  94. Stephanie says:

    The problem I have with the solution in #89, and the previous solutions that use spans styled with display:block, is that it violates a basic accessibility rule: pages must be readable without their associated stylesheets. (WCAG 6.1, a priority 1 checkpoint.)
    A is by far the simplest and clearest solution.

  95. Sharaf says:

    How about this?
    ABC Widgets, Inc.
    100 – 1234 West Main Street
    Anytown, State
    Zip
    Ph: 555-555-1234
    Fax: 555-555-1234
    Style the ul so that the bullets don’t show up.

  96. Sharaf says:

    Oops…
    I meant:
    ABC Widgets, Inc.
    100 – 1234 West Main Street
    Anytown, State
    Zip
    Ph: 555-555-1234
    Fax: 555-555-1234
    For some reason my ul and li tags are not showing up when I posted the previous comment.

  97. Laura says:

    There really aren’t that many choices for semantic mark up for something like this.
    It is usually best to use <div> rather than <br /> for line structured content. A screen reader would just blast through <br />s without pauses. Using a list fixes the screen reader issue, but is a kludge because contact information isn’t a list, is it?
    The address element would be great to use but it indicates “contact information for a document or a major part of a document”. That is, it is for the author’s address, and hence for a specific purpose. And you would need to add line breaks since for some odd reason, HTML was defined so that only inline content (and the p element in Transitional version) is allowed inside address.
    I’ve considered two other options.
    1. Instead of using the address element, another option to consider is <div>:
    <div class="address">
    <div class="name">ABC Widgets, Inc.</div>
    <div class="street">100 - 1234 West Main Street</div>
    <div class="citystate">Anytown, State</div>
    <div class="zipcode">00000-000</div>
    <div class="phone">555-555-1234</div>
    <div class="fax">555-555-1234</div>
    </div>

    This gives:
    1. Line breaks by default (just as <br /> gives).
    2. No other formatting by default, so you can start styling without first worrying how to switch off something.
    3. Hooks to attach styles to as desired.
    You can of course omit class attributes if you don’t need them. And using a heading element on the name would not be wrong. Using strong on the name imaginable too.
    2. Data Table Option
    I think contact information is really an implied table. So perhaps the most logical (or least illogical) and most accessible approach would be to use an explicit data table:
    <table summary=
    "This table contains contact inforamtion for ABC Widgets, Incorporated.">
    <caption>Contact inforamtion for ABC Widgets, <abbr title="Incorporated">Inc.</abbr>
    </caption>
    <tr>
    <th scope="row">Address</th>
    <td>100 - 1234 West Main Street</td>
    </tr>
    <tr>
    <th scope="row">City</th>
    <td>Anytown</td>
    </tr>
    <tr>
    <th scope="row">State</th>
    <td>AnyState</td>
    </tr>
    <tr>
    <th scope="row">Zip</th>
    <td>00000-0000</td>
    </tr>
    <tr>
    <th scope="row">Phone</th>
    <td>555-555-1234</td>
    </tr>
    <tr>
    <th scope="row">Fax</th>
    <td>555-555-1234</td>
    </tr>
    </table>

  98. Jason says:

    I choose A, the address tag is the only solution that semantically captures the information within as an address.
    Except I don’t believe the phone and fax number should be inside the address tag, as they are not an address, they are phone numbers.
    BUT, according to the W3C Spec
    “The ADDRESS element may be used by authors to supply contact information for a document or a major part of a document such as a form. This element often appears at the beginning or end of a document.”
    Since phone numbers are contact information, I can’t argue to hard against them.
    RE: #53/54 ACJ
    The pre tag cannot go inside the address tag, as the address tag can only contain inline elements.
    According to W3Schools:
    “The address usually renders in italic. Most browsers will add a line break before and after the address element, but line breaks inside the text you have to insert yourself.”
    They go on to show an example of an address using the <br> element.

  99. Jason says:

    Oops, there was supposed to be something separating two of my thoughts in that post, between my response to #53 and the “according to …” link.
    That was:
    pre would be nice to keep the line breaks and formatting of an address, but since we can’t do that, BR is the next best thing

  100. A note on code formatting: I’m not sure why, but many are assuming that any HTML that is put in the comments will be magically formatted from whitespace, and encoded with entities. Please encode any code before you submit. Also, line breaks and paragraphs are automatically generated, so there’s no need to add those in. Thanks. Someday, I should figure out a better way to handle code examples in the comments.

  101. Jason says:

    I like A but why all the <br> tags?
    Why not wrap each line with <address> ?

    <address>ABC Widgets, Inc.</address>
    <address>100 - 1234 West Main Street</address>
    <address>Anytown, State</address>
    <address>Zip</address>
    <address>Ph: 555-555-1234</address>
    <address>Fax: 555-555-1234</address>

    If the original question asked how would you structure address information in one line block (for a footer maybe) then I would choose this:

    <address>ABC Widgets, Inc. 100 - 1234 West Main Street Anytown, State Zip Ph: 555-555-1234 Fax: 555-555-1234</address>

    Seems Simple enough to me.

  102. Anonymous says:

    I feel that an address/br combination is the absolute right choice. Not only that, but it uses less bandwidth than all the other solutions. Not to say that the bandwidth saving solution is always the right one, but in this case it is. No need to re-invent the wheel, people. These tags are here for a reason.
    Also, the address tag is not limited to addresses only. It also declares authorship, which a lot of people overlook, but there is probably a lot I overlook as well. We can only try our best.

  103. Michael Smith says:

    After reading and thinking some more about this, I’m settling on;
    <address>
        ABC Widgets, Inc.<br />
        100 – 1234 West Main Street<br />
        Anytown, State<br />
        Zip<br />
    </address>
    <address>Ph: 555-555-1234</address>
    <address>Fax: 555-555-1234</address>
    I would have prefered to use an OL rather than BR’s for the street-address, but as Jason mentioned earlier, ADDRESS can only contain inline elements.
    I also do feel that the phone and fax numbers are not part of the street-address, but are kind of alternate addresses.
    You could throw a DIV around the whole caboodle, but that’s probably 6 and 2 3′s.

  104. Kim Siever says:

    I use A.
    I use <p> for paragraphs, <blockquote> for a block of quoted text and <em> for emphasis. why wouldn’t I use <address> for an address?

  105. Kim Siever says:

    Pete Lasko said: “If you want to hide it, don’t write it in the first place.”
    Couldn’t agree more. If NN4.x or cell phone users will see it, why not let everyone see it?
    Oh, and, FWIW, earlier specs do use a postal address as an example of the <address> tag. Not sure why this change came about; no explanation is ever given. Nevertheless, I do not get the impression from anything in the spec (outside of the example) that says the address tag can only be used for specifying the document’s author. After all, my postal address (or even my phone number and e-mail address) would most certainly qualify as “contact information for a document” on my website.
    With regards to the suggestion to use “white-space: pre;” instead of <br />, it sounds cool but what will the unstyled version look like? each of the address components will come after each other, not even separated by punctuation. I’m not sure that’s the right way. I suppose one could add commas in the code so that all versions would have the commas, but most postal address on envelopes are void of punctuation.

  106. Egor Kloos says:

    I’d still go for [a]. Maybe with a few tweaks, I can see the icons now ;)
    <address class="company">
      <span class="name" title="Company name">
       Meglomaniac
      </span>
      <span class="street" title="Street name">
       1, Kingstreet
      </span>
      <span class="loaction" title="City and State">
       Gotham, NY
      </span>
      <span class="zip number" title="Zip number">
       90210
      </span>
      <span class="home number" title="Home phonenumber">
       555-555-1234
      </span>
      <span class="company number" title="Company phonenumber">
       555-555-1234
      </span>
      <span class="fax number" title="Fax number">
       555-555-1234
      </span>
    </address>

  107. riccard0 says:

    Definitely A.
    Although the proposed modifications to force line breaks without brs could come handy if a redesign calls for a one-line address.

  108. Laura says:

    The element is semantically empty, so it can be used for anything, and it’s really not adequate for anything; together with , it’s essentially XML in old HTML clothes.

  109. Laura says:

    The span element is semantically empty, so it can be used for anything, and it’s really not adequate for anything; together with div, it’s essentially XML in old HTML clothes.

  110. George says:

    just make it an image :D

  111. A, although I’d drop the last <br />. If you wanted to denote a company’s name, etc., that’d be a perfect place for a <span>.

  112. Jim Dabell says:

    “earlier specs do use a postal address as an example of the <address> tag.”
    I don’t think anybody is arguing that it’s not suitable for postal addresses.
    “I do not get the impression from anything in the spec (outside of the example) that says the address tag can only be used for specifying the documen’s author.”
    It’s contact information for the document. Not contact information in general. Sure, if your address can be described as a contact address for the document, go ahead and use the <address> element type. But that doesn’t mean that you can indiscriminately use it for all types of address.

  113. bryan says:

    Sure, you can mark it up however the heck you want to…but I thought the point of this exercise was to figure out how to preserve the data without overburdening it with presentation. I mean, if you wanted to, I could mark the whole thing up with <form> tags and overwrite them to display an address in standard postal format. But it loses the meaning.
    Optimally, the contact information should be rewritten with XML and parsed appropriately. However, in dealing with just Strict XHTML, encapsulating your data leaves you with few pre-made tags to use.
    From the top, an analysis of the example. The original address is:
    ABC Widgets, Inc.
    100 – 1234 West Main Street
    Anytown, State
    Zip
    Ph: 555-555-1234
    Fax: 555-555-1234
    Now, there have been arguments about the correct use of the <address> tag. We’ll alleviate all those now by saying that my design company is ABC Widgets, Inc. That disolves all arguments about whether the address tag itself is being used properly, for now I am the author of the page and my address should be included for contact purposes. We’ll even go so far as to say I want this address on every page. Now, it would be silly to copy and paste to each page I create for the site, as if we relocate, I’d have to go back and reedit each instance. So, we’ll put it in a server-side include. Now, there may be different ways we need it displayed. First, however, let’s look at the different types of information we have within the address alone. Breaking the address apart visually, we have the following data types:
    Suite: 100
    Street Number: 1234
    Street Direction: West
    Street Name: Main
    Street Type: Street
    City: Anytown
    State/Province: State
    Postal Code: ZIP
    Phone Area Code: 555
    Phone Exchange: 555
    Phone Unique: 1234
    Fax Area Code: 555
    Fax Exchange: 555
    Fax Unique: 1234
    Unfortuantely, there does not already exist any XHTML tags to mark these up with. There is no <street> tag, or <phoneareacode> tag. But we still have to wrap the sections individually. For example:
    (555) 555-1234
    555.555.1234
    555-555-1234
    5555551234
    Four different presentations of the same data. Different areas of the world use different formats, so if you mark up sections as you should with lang attributes, why not also ensure that different visitors can view your contact information in the manner that is most familiar to them? The advantages of the method I used in #61 are that by default, your address formats to:
    ABC Widgets, Inc.
    100 – 1234 West Main Street
    Anytown State
    Zip
    555 555 1234
    555 555 1234
    Sure, the spacing between lines is a bit much, but it’s not unmanageable. From there you can use CSS to make things presentational. . between the sections of the phone numbers. , in the physical address to make comprehension a bit easier. Ph: and Fax: for at-a-glance recognition of what the numbers are for, in case you’re not familiar with common ordering. All added using CSS :before, :after, and content:. And they can be customized based on intended audience.
    We also have the new trend of adding ids to their <body> and <html> elements so that visitors can make their own site-specific style sheets. Nevermind basic user style sheets that are applied to every page that could use the code I presented in #61 to format address information however they’re used to anyways.
    What this all boils down to is that correct semantic markup that does not break the meaning of either the elements or the actual data itself will give you and the users of your site more control over presentation. More control gives you more possibilities. No one is required to do this. Still the majority of “designers” out their cannot even manage to get valid HTML 4.01 spit out, and are frequent users of the “Best viewed in” clause. That should be an indication that the common way is not the best way. Criticize, mock, and scorn all you want for “overcomplication” or whatever excuse you can come up with, but I’d bet that a lot of those who shun the methods I’ve suggested as “too complicated” or “too hard” also criticize Microsoft for their horrible programing practices, especially when it comes to IE.

  114. Janco Tanis says:

    D. and go with the address element and the css rule
    address { white-space: pre; }
    I would not use the different spans to add the various address elements as were not coding xml for data exchange. the line breaks are only for readability so therefor css will do.

  115. Laura says:

    With using the address element and the css rule { white-space: pre; } as in 115, you wouldn’t be able to do things that relate to the line structure, since in this case the line structure does not exist in the element structure. You also have the accessibility problem of a screen reader just blasting through without pauses.

  116. Jim Dabell says:

    “You also have the accessibility problem of a screen reader just blasting through without pauses.”
    Put commas in.

  117. Nick says:

    Put commas in.
    But commas aren’t part of the address. Adding extra characters is just as bad as adding extra tags.

  118. Louis says:

    I must admit that I’ve not read all of the comments. There are just too many!
    However, my opinion is that (X)HTML does not contain the expressiveness that we need in this situation. My typical response to this problem, would be to use XML (in the way nature — er, sorry W3 — intended).
    So, I would plump for option D. Moreover, I’d use something similar to Thomas’s solution.
    However, I am a fan of containment. Having to write seperate styling for the XML address would be a bit of a turn-off. The other sensible alternative would be option C or a variation on it, in my opinion.

  119. Tino says:

    you guys are crazy ….
    IT’S “A” … it’s very simple.

  120. Jim Dabell says:

    “But commas aren’t part of the address. Adding extra characters is just as bad as adding extra tags.”
    I always put commas at the end of each line when writing, typing, or marking up addresses. It’s normal to do so as far as I am concerned.

  121. Wow, that’s a lot of comments. I initially thought that A made sense. The controversy about the intention of the spec is interesting, but thinking through cases where I would include an address of sorts on a page, the requirement from the spec that the address tag contain “contact information for a document or a major part of a document” strikes me as a pretty loose requirement:
    1. A contact information page for a department of a company or institution could use the address tag.
    2. A reference in a page to an individual followed by their address could also appropriately use the address tag, as that address would amount to contact info. for a major “part of a document.”
    3. Even a list of resources with relevant contact information could make proper use of address because each resource entry constitutes an important “part of a document” for which the address counts as contact information.
    So I’m willing to accept that the address tag is appropriate for addresses in nearly all common cases. In uncommon cases, the tag would not be semantically appropriate, more on that later.
    David’s recognition that “The [address] tag defines the start of an address. You should use it to define addresses, signatures, or authorships of documents.” made me think that there might be better options than A, options like the solutions offered by Jason and Michael Smith where the address tag is used to mark-up each different type of address separately.
    Michael’s solution, where each address tag contains a full address seems like the best option. Optionally, <br />s could be added to allow for line breaks and <span>s could be inserted to allow for independent styling of different elements, (but display: block applied to span seems to me to violate the rule that address can’t contain block level elements.
    For any addresses that somehow fall outside of what the spec might allow, replace the address tags with <p class="address">.
    This solution is semantic (unlike B or C), it degrades well (unlike A, all essential line breaks display in no-CSS browsers), and it’s less complicated than C. So, my vote is for D.

  122. I’m somewhat suprised with the amount of the comments on such a simple question.
    I wasn’t going to add more but I guess some people just misunderstand the concept of the SimpleQuiz.
    We’re not talking about how certain data should be marked up in your database. Imagine you have some initial source, say, XML. We’re talking about how to represent it on the World Wide Web with XHTML (not with your proprietary format).
    Dan, this could be made more clear.

  123. I love the web standards community. You guys are doing my job here!
    Presenting names, adresses and phone numbers on a web site is the most important part of my job descriptional — I work as a web designer for a Norwegian phone book/information service.
    So far we’ve been using tables in our phone book on the web, but that might change.
    Lots of good suggestions here. Since everything has been said (or so it seems) I’ll share a few thoughts I’ve been puzzling with in job situations.
    When I first saw the quiz, I initially came up with the same as Jacob Patton suggests in comment #2. I’ve been thinking about using dls earlier, and appretiate this being discussed.
    The big difference: A phone book has more than one name and address. In my company’s phone book on the web, presentation is as an important issue as markup. We have to be pragmatic in the real world (hence the use of tables so far.) What would be great is a solution where the CSS determines how everything is listed.
    The folks who use our service might differ in their preferences. Some want it all on one line with a new name for each line (something a table handles very well), some like to see the address below the name and the phone number aligned to the right side of each name and address (that’s how we do it today). Any suggestions on how to accomplish these two variations without altering the html docs? Maybe a bit on the side, but still on topic (or maybe a topic for another SimpleQuiz?)
    I also have a question conserning the address-tag (I haven’t used the tag since… it must be 1996.) The specs say it’s supposed to be used for the page owner’s address. Would it be wrong to use it on every address in a phone book?

  124. Eli says:

    I say “D”. I use something like this:
    <address>
    <div>ABC Widgets, Inc.</div>
    <div>100 – 1234 West Main Street</div>
    <div>Anytown, State, ZIP</div>
    <div>Ph: 555-555-1234</div>
    <div>Fax: 555-555-1234</div>
    </address>
    divs divide up the address into component parts. If I need to style individual parts of the address I’ll add id hooks on the individual divs

  125. Lachlan Hunt says:

    > Using A is for me no good. The BR
    > tag tag is a visual tag. Using EM,
    > STRONG, B or I is just as bad,
    > because again they are added to
    > create visuals.
    While <br> may have many presentational abuses, it is actually semantic, though not structured as nicely as <l> in XHTML 2.
    Most of the time it’s presentational when two are used successively, instead of a new paragraph or possibly using <pre> without using any <br/> elements (if appropriate for the semantics of the content).
    When it’s used as in example A, it’s a semantic use, not just a presentational one.
    <strong> and <em> are not presentational either, as you said they are, however, now that people are finally learning that <b> and <i> are presentational, I’m starting to see people who use them for their presentational effects, rather than their semantics.
    eg. I see a lot of:
    <td><strong>heading</strong></td>
    instead of:
    <th>heading</th>