So address tags are rubbish for microformat hCards?
Did I mention that you learn something new every day? I just answered a question on CSS discuss about styling BR elements in andADDRESS element (don’t ask) and got all microformaty by offering spans inside the address with all kind of hCard goodness as the solution.
I thought I was in the know as even Tantek used them in his elements of XHTML presentations. However, Bradley Wright turned around with a smile on his face and told me that ADDRESS is bad choice for a hCard, as when you look at the specs of HTML 4.01, you find in the ADDRESS section:
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.
Which means it is semantically there to provide a contact option for this document, and not for a physical locationnot for a physical location of a product the web site advertises or an address of someone the article talks about. Brad, of course had this from another person that has too much time to read the specs: Mark Norman Francis as they had argued about that earlier because of an hCard integration in a company property.
So, is this the end of ADDRESS? Seeing that it is an inline elementthat it doesn’t allow for nested paragraphs in HTML 4.01 strict, I always considered it a bad choice for marking up an address anyways.
Update
We were too late with this discussion, actually. Tantek explained the logic of it in 2005 on the microformats list and it is also part of the hCard FAQ.
Dear me, bad research on my behalf.
September 27th, 2006 at 7:41 pm
“Which means it is semantically there to provide a contact option for this document, and not for a physical location.”
Not necessarily; it doesn’t say that the contact information can’t be a physical location, it just says that the contact information must be related to the document that it’s on. So if somebody’s written a document, or is the maintainer of that document, but that person doesn’t have an email address or their own webpage (for whatever reason), I see no reason why the <address> can’t be a physical location instead. You’re just inferring that it can’t be, it’s not explicitly forbidden by the spec.
September 27th, 2006 at 8:45 pm
To add to what Paul has said, the HTML 3.2 spec included a physical address as an example of the ADDRESS element. I guess that this was a leftover from the time when documents were put on the Web but the original author might have no contact address apart from a physical address, i.e. no email address or URI. Considering how unusual that would be a couple of years later, I assume that by the time it came to write the HTML 4.0 spec they dropped this physical example. However, I can’t find anything in the HTML 4.0 spec to say that its usage has been limited to only online addresses.
September 27th, 2006 at 8:56 pm
I’d have to agree with Paul. As long as the address provides contact details for the person responsible for maintaining the page or form I don’t see why it shouldn’t be a valid to use address.
September 27th, 2006 at 9:53 pm
addressis a block-level element.September 27th, 2006 at 10:10 pm
How so zcorpan?
September 27th, 2006 at 10:37 pm
The ADDRESS element is a block-level element. I believe that in the first line you quoted from the spec, the (%inline;) part says the ADDRESS element can contain one or more inline elements. (The P element is also similarly described in the spec).
September 28th, 2006 at 4:43 am
I never fully understood the ADDRESS element. It’s quite confusing, and even the name of it is a oxymoron. Now is that semantic?
September 28th, 2006 at 9:52 am
In Norm’s (and possibly my) defense, the use case which brought this discussion up was to do with marking up an entire directory of addresses using hCard and the Address element. Which is obviously wrong, given the spec.
I still feel it’s a bit of a grey area, and agree with Tantek when he says it’s “badly named”.
September 28th, 2006 at 6:08 pm
@ Chris Heilmann and Phil Pickering
Just to clarify, it is not necessarily the definition of the element which specifies if it is a block or an inline level element, but whether rather if that element belongs to the set of block or inline (or flow) level elements.
< !ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">
</>