Use of ADDRESS Element
After seeing it mentioned in Transcending CSS and then again in Pro CSS Techniques, I think there may be a general misconception as to how the ADDRESS element should be used.
In neither case did the authors explain how or why the element should be used. In fact, it seemed implied that it should be used to mark up any postal address that might find its way onto a web page. In the argument of semantics and the proper use of the HTML standard, this would be inaccurate.
"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."
~ http://www.w3.org/TR/html401/struct/global.html#h-7.5.6
Therefore, if the contact information for a particular document happens to be a postal address, then by all means, use the address element.
May, should or must
Some may argue that the use of "may be used" (vs. "should", or "must") opens the door to other possible uses. However, one only has to look at the use of "may" in other places within the W3C spec to realize that this isn't the case.
For example,
"Unlike A, it may only appear in the HEAD section of a document"
~ http://www.w3.org/TR/html401/struct/links.html#edef-LINK
Even though they use "may", they really mean "should" or "must".
Microformats
Instead, an hCard or adr microformat would likely be the best way to mark up your address. The examples page even includes some proper examples of using the ADDRESS element in conjunction with the hCard specification.
Conversation
While I agree with your statements, I don't agree with your comparitive example: .
The reason being, there is a significant difference between the two quotes. The word 'only'. If the former was written , then the comparison would be valid. In this case however, I don't think it is ;)
Cheers
Well, first off, Pro CSS Techniques is about CSS, not about (X)HTML, so it doesn't go into a lot of detail about markup at all. Examples of how or why the address element should be used would definitely be outside the scope of our book, which is why you didn't find them in Pro CSS Techniques.
That having been said, I'm not sure I understand what you're getting at. You say, "Instead, an hCard or adr microformat would likely be the best way to mark up your address."
I would agree. But a microformat is only a set of class names. It has nothing to do with the HTML elements involved. So why wouldn't the best solution for a postal address be to use the address element and class names from a microformat?
When we suggest that someone should use the address element to mark up a postal address, we are in no way suggesting they shouldn't use a microformat also -- they're two totally different things, and they're not mutually exclusive.
Tangentially, I'm not particularly sold on the real-world benefits of microformats. Microformats are a nice idea, and there certainly can be no harm in using them, but I still don't see a lot of value being added for anyone but the biggest of power users when they're used.
Perhaps someday a great consumption tool will make microformats really useful in the real word -- but I've not seen it yet. Pro CSS Techniques is all about the real-word context. And that is why there isn't much emphasis on them in Pro CSS Techniques.
I have absolutely no idea which is the correct use of 'address', but I have to disagree with your linguistics.
There's a big difference between "may" and "may only". Example:
1. You may have a cookie.
2. You may only have one cookie.
Obviously #2 is setting a limitation, and has a meaning similar to "should" or "must", but #1 in no way implies that you MUST have a cookie.
Okay, I'm being anal, but I think it's important to realize that the W3C does use ambiguous language, and it's not always clear what they mean.
On another note, I've seen ADDRESS used to mark up email addresses. Is that wrong?
@ Michael Moncur: I personally would never use the ADDRESS element to markup up an email address. I would also use an anchor, so it's clickable, and usable with the users address book/email preferences.
Although the specification does say 'The ADDRESS element may be used by authors to supply contact information for a document' and this can be applied to any information, including an email address, I think an anchor is much more appropriate.
@ Ian: & Michael That's a great point.
I personally do not like restricting the use of the ADDRESS element simply to contact information of the author of the specific document/page you're on. This is so limited. I personally use it for addresses, and I find that perfectly acceptable.
@ Jeff: I don't think Jonathan was saying you should use microformats instead of semantic HTML, although, it's not entirely clear.
A lot of the time I do the following, which is using the semantic HTML mentioned, as well as adding in microformats...
@Ian/Michael: Ack! Yes, I must concede on the 'only' qualifier. I do believe there were other examples and I may have chosen poorly.
@Jeff: I certainly understand that the book is about CSS but the concern was that the example used was in a particular section of the book that was specifically discussing semantic HTML, and not just some random example in the book. As I said above, in both books, the message seemed to come across as, "don't use a paragraph tag, use an address tag!" It may not be how it was intended but that's the way it came across to me.
Microformats are not just class names, but also have to do with semantic HTML. In other words, if I used a URL class on an acronym when I shouldn't have, I'd consider that an incorrect microformat. Semantic HTML and proper class elements go hand in hand (which, if I'm not mistaken, was the point of that section of the book).
While my last paragraph starts off seemingly separating microformats and the address element, I specifically link to examples where both are used together. In the book, I don't fault that you don't mention microformats. And there may certainly be times when an address element will be the appropriate element. My concern was that it seemed to imply that all postal addresses should be marked up with address tags.
The real-world benefits of microformats are currently limited and I don't think they needed to be covered in the book.
@trovster: the address element is meant to contain document contact information, be that a postal address, an email address (as is the example from previous W3C specs), or a bunch of links to the people in charge of maintaining the page (as is the example used in the current W3C spec).
@Everybody: finally, and something I'm totally cool with because, believe me, I'm no standards nazi, maybe it's possible that through past misuses of the address element we can use it for all postal addresses. If nothing takes advantage of it now there'd certainly be no harm in that.
Oh, and before Jeff thinks I'm out to discredit his book, I'm 4 chapters in and it's quite good. :)
However, one only has to look at the use of "may" in other places within the W3C spec
Actually one has to look at the spec on these keywords - not go guessing...
Using <address> is optional, but if an author chooses to use it, then the spec is clear how it should be used.
My 2 pennies on the may/may only issue: look at the context. If 'must' was used, it would have implied that the <address /> element must always appear within a <form />, which is clearly not the case.
The statement seems to be more 'may or may not' than 'may and may also', and I think interpreting it otherwise is really stretching the rules of W3C interpretation.
Yeah, that pretty much was the message -- and although it's not an absolute I do think I'd agree with that message 95% of the time.
Really? It sure seems to me that they are. You can create an hCard with any set of elements -- it's all about what classes you put on them. Maybe I'm missing something, but my understanding is that the (X)HTML element(s) used are irrelevant in microformats, and the important thing is conforming to the pre-defined set of class names. Is this inaccurate?
Ohhh! Now I think I finally understand! So you don't think our example was wrong, you just think we should have mentioned that it's not the only way to mark up an address every time. I get it now.
Maybe we should have clarified that. I dunno. The semantic HTML chapter is a very quick overview/reminder aimed at someone who already understands the basics. I don't know if we have time in that chapter to cover all of the possibilities.
The message is supposed to be, "try to use a semantic element if there is one available to you, instead of using an element that doesn't make sense for the content." If we said anything that deviates from that message, then we messed up. Sorry about that.
And sorry I was so confused about what you were trying to say. I responded after coming home from a New Year's party -- so there's a good chance I wasn't reading it all clearly. :)
@ Jeff: Some microformats such as hAtom, and hCalendar use the ABBR element. This is called the datetime-design-pattern. But mostly, microformats are 'just class names' with a few rel and title attributes thrown in too.
@ Jonathan: Yes, I know what the specification says, but like I mentioned, I think an anchor is more appropriate for an email address, and that I'm totally and utterly agreeing with you, on the use of address for marking up postal addresses (through past misuses).
"In neither case did the authors explain how or why the element should be used. In fact, it seemed implied that it should be used to mark up any postal address that might find its way onto a web page."
I've not devoured all of Jeff's (so far terrific) book yet, but in Transcending, I do say that "[the address element] was not designed for use with physical addresses but with contact information for a particular page..."
Personally I think that as with some other elements in HTML/XHTML (namely the definition list element) there is some room for flexibility in the application of <address>. As you rightly say, if the contact method for a page is either a postal address or even a telephone number, then <address> would be appropriate.
@trovster: thanks for the clarification! :)
@Malarkey: I probably missed where that actually got mentioned. On page 43, where you talk of microformats, you've used the address element in a way that would be accurate but I read as being all encompassing. "Hey, I've got an address, I better use
address."That's one of the difficult parts of writing a book, I suppose. You want to explain things but not have to create tangents on every single point.
In Transcending CSS, see the sidebar note on page 86. Malarkey is right, all of this confusion is the result of unfortunate naming of the element. When I first learned of it I thought what everyone thought, "oh look, an element just for marking up addresses!"
<plug>But fear not, I'm making a point of clearing up the confusion in my book </plug>.
For my money, the contents of an address element should always relate to the document (or perhaps the entire site), whether it's a postal address, an email address or just a byline. So I've redefined it in my mind as an "author" element that just happens to have the wrong name.
If the information relates to an external entity a different element should be used.
For what it's worth, the current working draft of HTML 5 is much clearer on this:
Not much wiggle room there.
And wouldn't it have been nice if I had also included a link to the relevant part of the specification.