[Bug 11562] address tag definition has no relation to it's name

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11562

--- Comment #4 from arieh glazer <arieh.glazer@gmail.com> 2010-12-16 18:36:31 UTC ---

> Please note that HTML already includes a native way to unambiguously mark up
> locations using hyperlinks:
> 
> For example:
> 
> <a href="http://example.com">Destination description</a>
> 
> <a href="mailto:somebody@example.com">somebody@example.com</a>
> 
> <a href="tel:+358-555-1234567">Tel: +358-555-1234567</a>
> 
> <a href="fax:+358.555.1234567">Fax: +358.555.1234567</a>
> 
> <a href="geo:48.2010,16.3695,183">Vienna, Austria</a>
> 
> See also:
> 
>    * http://tools.ietf.org/html/rfc6068 for mailto
> 
>    * http://tools.ietf.org/html/rfc5341 for tel and fax
> 
>    * http://tools.ietf.org/html/rfc5870 for geo

I was not aware of these. These seem like a valid use, though my point was
about specificaly marking up a location that is not exact (or it would have
been easy to use it as a contact information). It is for that use case that I'm
arguing address should be allowed to be used.

> 
> Microdata and HTML+RDFa (another option for annotating HTML5 with additional
> semantics) have the same "standard" status as HTML5: they are on track to
> becoming W3C Recommendations:
> 
> http://www.w3.org/TR/microdata/
> 
> http://www.w3.org/TR/rdfa-in-html/
> 
> I think it's ironic that you are arguing we should *change* the definition of
> the "address" element from author contact information - the definition it has
> had since 1993 - to simply mean any old address on the basis that HTML is a
> reliable standard!
> 
> http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
> 
> http://www.w3.org/MarkUp/html-spec/html-spec_5.html#SEC5.5.3
> 
> http://www.w3.org/TR/html401/struct/global.html#h-7.5.6

technically this is correct, but as the address is already a part of HTML, it's
support already exist, unlike the RDFa/MD specs which are unsupported by some
major browsers, and are not even prommissed to see support. Using RDFa
correctly on a page means no current IE version can open it (other than
declaring the doctype - I mean the ability to use the content as XML).

> > In most discussions I've participated on the subject, such markup as:
> > <li class='game'>
> >    <h3>Some1 vs Some2</h3>
> >   <address>Some city</address>
> > </li>
> > was considered off the spec.
> 
> Correctly so. That is not author contact information, it's just a location.
>
That much I understand. My point is that it should (that's basically my entire
case).


> It's more suited since that has *always* been the definition of "address".
> 
> > As I see it, it makes more sense that the tag should be used as a generic
> > address/contact info, rather than a very specific, less useful "contact the
> > owner of the document" tag (which can be expressed by many other means, such
> > as title, rel and other MF/MD which are for special cases scenarios).  IMO,
> > HTML should be as generic as possible, as to allow a large set of different
> > valid markups..
> 
> Precisely because HTML is supposed to be a reliable standard, we should be wary
> of arbitrarily changing the semantics of its elements and attributes.
> 

I am not suggesting to change the semantics of the element, just to broaden it.
Saying it can also have another use case doesn't cancel the old one. And as I
understand, the _original_ meaning did include my use case. It was dropped
later on (I think on H3).

> The name of an element/attribute alone is a very poor reason to change its
> semantics.
> 

This depends. I guess it's more of a philosophical question, but IMO html
should be readable and understandable to humans as much as machines. But my
point is that although the current use case vaguely falls into the semantics of
the word "address", the semantics should include a broader spectrum of meanings
(I know - repeating myself unnecessarily)  

> Incidentally, it wouldn't particularly surprise me if it were used more often
> incorrectly, but we should be careful to make decisions based on actual data.

Agreed - we should be careful. But it is still a point to consider. Or rather -
we should consider why that is. If the reason is a one that doesn't break
support or behavior, and can be explained by a lack of a better solution it
could be a valid point. 

> I think we can conclude the claim "search engines recognize it as such" is
> unsubstantiated and should not be taken into account.

Agreed.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 16 December 2010 18:36:34 UTC