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
-
<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>
-
<div>
<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>
-
<dl>
<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>
- None of the above, or a combination of the above.
126 Comments
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.
D. What about a slight modification of C:
<dl>
<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.
Also, I’m talking about each adding hooks to each term element, individually, in the last sentence, of course.
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.
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.
I’ve always gone with A. That is what the
addresselement is for, marking up addresses. Andbrhas 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
addresstag 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
brtag seems to make the most sense…*sticks up hand* First timer alert!
For a start, I didn’t even know an
addresstag 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!
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
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>
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.
Hmm… funny. I used SimpleCode to create the <code> block, but it looks rather strange
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&emare 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 anaddresstag.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.Thomas – SimpleCode adds
brtags, and then MT adds another line break automatically. I need to figure out a better way to filter stuff.‘That is what
strong&emare for.’That’s not true. They are used for emphasis and stronger emphasis. You should then actually use
iandb.And
address… It’s made for it. I guess A, because semantics must make sense, andaddresscouldn’t make any more sense.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.
;)
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”.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.
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.
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!
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?
A
why not go with a modified version of A, which seems to be the most semantically sound approach. Instead of using
brtags why not specifywhite-space: pre;for theaddresstag in your stylesheet?you could even add the following to style different parts of the address as needed:
<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>
then in your stylesheet:
address {
white-space: pre;
}
address .name {
font-weight: bold;
}
etc…
I’m split, as I so often am.
On the one hand, I feel that
addresstag 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.
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
spantag, and class it appropriately as phone, fax etc.Spanandbraren’t deprecated; forcing an address into a dl would be the semantic equivalent of forcing it into a table.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 theclass="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>.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 :-)
A, for sure. I didn’t know it existed, but it sure makes sense.
and now to go change my markup…
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.
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. =}
Hi Dan :)
Using
addressis 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… ;)
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!
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.
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.
street person element anytown because
for its contents. This is a safe-cache copy of the original web site.