Comments on: Depricate the address element? http://alastairc.ac/2006/12/depricate-the-address-element/ Kything web interactions Fri, 13 Apr 2012 05:33:39 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Ben 'Cerbera' Millard http://alastairc.ac/2006/12/depricate-the-address-element/comment-page-1/#comment-15149 Ben 'Cerbera' Millard Thu, 17 May 2007 11:04:12 +0000 http://alastairc.ac/2006/12/depricate-the-address-element/#comment-15149 If you hadn't seen it, I put my idea for loosening <code><address></code> to WHATWG in <a href="http://forums.whatwg.org/viewtopic.php?t=5" rel="nofollow">Should <code><address></code> be more general-purpose?</a> on their forums. Zcorpan, Hixie and Lachy all commented on it but nothing has been decided yet. :) Go throw your two penneth in if you've ideas for this element! If you hadn’t seen it, I put my idea for loosening <address> to WHATWG in Should <address> be more general-purpose? on their forums. Zcorpan, Hixie and Lachy all commented on it but nothing has been decided yet. :)

Go throw your two penneth in if you’ve ideas for this element!

]]> By: Ben 'Cerbera' Millard http://alastairc.ac/2006/12/depricate-the-address-element/comment-page-1/#comment-8461 Ben 'Cerbera' Millard Sat, 02 Dec 2006 12:52:36 +0000 http://alastairc.ac/2006/12/depricate-the-address-element/#comment-8461 My position is to loosen it's meaning for HTML5. The meanings of other elements are being adjusted to better reflect common usage, and using <code><address></code> for marking up any sort of contact information would be more useful in practise. Since UAs don't do anything special with it yet, maybe that would find some traction and the change would be made. Address wasn't one of the <a href="http://code.google.com/webstats/2005-12/classes.html" rel="nofollow">top <code>class</code> values</a> so it's difficult to find figures for what people are currently using for contact information. However, just about every website I visit has a contact page with details that are relevant beyond that section of that page. The only time I see <code><address></code> being used as specified in HTML4 is on W3C pages and Apache documentation...which is hardly common. Since making the semantics less restrictive would still keep it compatible with existing UAs, I think that's a feasible option. My position is to loosen it’s meaning for HTML5. The meanings of other elements are being adjusted to better reflect common usage, and using <address> for marking up any sort of contact information would be more useful in practise. Since UAs don’t do anything special with it yet, maybe that would find some traction and the change would be made.

Address wasn’t one of the top class values so it’s difficult to find figures for what people are currently using for contact information.

However, just about every website I visit has a contact page with details that are relevant beyond that section of that page. The only time I see <address> being used as specified in HTML4 is on W3C pages and Apache documentation…which is hardly common.

Since making the semantics less restrictive would still keep it compatible with existing UAs, I think that’s a feasible option.

]]> By: AlastairC http://alastairc.ac/2006/12/depricate-the-address-element/comment-page-1/#comment-8335 AlastairC Fri, 01 Dec 2006 14:04:08 +0000 http://alastairc.ac/2006/12/depricate-the-address-element/#comment-8335 Which bit was that from? The part I would refer to is the <a href="http://www.w3.org/TR/html4/struct/global.html#h-7.5.6" rel="nofollow">HTML spec</a>: <blockquote>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.</blockquote> HTML 5 is very similar (as you would expect from being backwards compatible), and makes it more explicit: <blockquote>The address element represents a paragraph of contact information for the section it applies to [snipped example] The address element must not be used to represent arbitrary addresses (e.g. postal addresses), unless those addresses are contact information for the section.</blockquote> XHTML 2 replicates the HTML 4.01 wording. It is also the <a href="http://microformats.org/wiki/hcard-faq#Should_I_use_ADDRESS_for_hCards" rel="nofollow">number 1 FAQ</a> on hCards, which concludes: <blockquote>In short, DO NOT use address to markup addresses in general. Only use it to markup the contact information for the page (or major part thereof), and when doing so, use it to markup the entire contact information (via address class="vcard"), not just the address of the contact.</blockquote> I agree that it wasn't very specific in the HTML spec, but the meaning that people writing specs have given it since is quite clear. That is quite a good indicator of what would be implemented (or not) in browsers & user-agents. I'm just saying that there is a divide between what web developers think it is for, and what the spec & browser people think it's for. Which bit was that from? The part I would refer to is the HTML 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.

HTML 5 is very similar (as you would expect from being backwards compatible), and makes it more explicit:

The address element represents a paragraph of contact information for the section it applies to
[snipped example]
The address element must not be used to represent arbitrary addresses (e.g. postal addresses), unless those addresses are contact information for the section.

XHTML 2 replicates the HTML 4.01 wording.

It is also the number 1 FAQ on hCards, which concludes:

In short, DO NOT use address to markup addresses in general. Only use it to markup the contact information for the page (or major part thereof), and when doing so, use it to markup the entire contact information (via address class=”vcard”), not just the address of the contact.

I agree that it wasn’t very specific in the HTML spec, but the meaning that people writing specs have given it since is quite clear.

That is quite a good indicator of what would be implemented (or not) in browsers & user-agents.

I’m just saying that there is a divide between what web developers think it is for, and what the spec & browser people think it’s for.

]]> By: Siegfried http://alastairc.ac/2006/12/depricate-the-address-element/comment-page-1/#comment-8331 Siegfried Fri, 01 Dec 2006 13:20:32 +0000 http://alastairc.ac/2006/12/depricate-the-address-element/#comment-8331 just from the w3c: <blockquote> ...specifies information <strong>such as</strong> authorship and contact details for the current document</blockquote> (emphasis added by me) just from the w3c:

…specifies information such as authorship and contact details for the current document

(emphasis added by me)

]]> By: Siegfried http://alastairc.ac/2006/12/depricate-the-address-element/comment-page-1/#comment-8330 Siegfried Fri, 01 Dec 2006 13:17:17 +0000 http://alastairc.ac/2006/12/depricate-the-address-element/#comment-8330 Are you sure that address is only specified for contact information for the pages author? Not for a pages contributor, publisher ore anything else related to that page? Only the author? Are you sure that address is only specified for contact information for the pages author? Not for a pages contributor, publisher ore anything else related to that page? Only the author?

]]> By: AlastairC http://alastairc.ac/2006/12/depricate-the-address-element/comment-page-1/#comment-8324 AlastairC Fri, 01 Dec 2006 09:39:10 +0000 http://alastairc.ac/2006/12/depricate-the-address-element/#comment-8324 Your right that <code>address</code> and hcard are not mutually exclusive. However, my point is that if you use <code>address</code> for contact information other than that of the document author, you are wrong (according to current and proposed specs). I believe that it why Microformats don't use it, because that would be misleading. (I'm fairly sure that is Tantec's opinion.) Therefore any functionality that user-agents implemented to take advantage of the element would conflict with it's current use. Oh, and by deprecate, I didn't mean eliminate, just not recommend for general usage any more. Your right that address and hcard are not mutually exclusive. However, my point is that if you use address for contact information other than that of the document author, you are wrong (according to current and proposed specs).

I believe that it why Microformats don’t use it, because that would be misleading. (I’m fairly sure that is Tantec’s opinion.)

Therefore any functionality that user-agents implemented to take advantage of the element would conflict with it’s current use.

Oh, and by deprecate, I didn’t mean eliminate, just not recommend for general usage any more.

]]> By: Siegfried http://alastairc.ac/2006/12/depricate-the-address-element/comment-page-1/#comment-8318 Siegfried Fri, 01 Dec 2006 07:18:18 +0000 http://alastairc.ac/2006/12/depricate-the-address-element/#comment-8318 The choice ist not hCard <em>or</em> address. The html elements (or tags) are bejond the scope of microformats. And hCard goes very well with address. Marking up an address container with class="vcard" and putting general (or not so general) contact information into this container is an optimal way to include this contact information in a web page. Additionally it is possible to further refine the role of the contact information container, independent of if this container is an adderess container or a div or whatever. Setting the class to vcard specifies this container to not only contain general contact information, but special contact information formatted according to the hCard specification. And f.ex. with Dublin Core it would be possible to further specify the <em>role</em> of that contact information (DC.creator, DC.contributor, DC.publisher) (see also: http://www.rorkvell.de/tech/dc). The suggestion to eliminate the address tag is no good idea. Just because it is rarely used does not imply that it is useless. It offers an <em>option</em>, which should be kept. The choice ist not hCard or address. The html elements (or tags) are bejond the scope of microformats. And hCard goes very well with address. Marking up an address container with class=”vcard” and putting general (or not so general) contact information into this container is an optimal way to include this contact information in a web page.

Additionally it is possible to further refine the role of the contact information container, independent of if this container is an adderess container or a div or whatever. Setting the class to vcard specifies this container to not only contain general contact information, but special contact information formatted according to the hCard specification. And f.ex. with Dublin Core it would be possible to further specify the role of that contact information (DC.creator, DC.contributor, DC.publisher) (see also: http://www.rorkvell.de/tech/dc).
The suggestion to eliminate the address tag is no good idea. Just because it is rarely used does not imply that it is useless. It offers an option, which should be kept.

]]>