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

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

--- Comment #5 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2010-12-16 19:05:46 UTC ---
(In reply to comment #4)
> 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).

Please note geo allows you to specify imprecise locations using:

http://tools.ietf.org/html/rfc5870#section-3.4.3

For example, you could specify a city by getting its center then specifying its
approximate radius as the value of the "u" parameter. Granted, that probably
isn't something authors are going to do.

> 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.

What sort of "support" are you worried browsers might not supply?

All popular browsers do with "address" is italicise it.

> 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).

Not so.

Currently, there is a plenty of deployed markup using RDFa in text/html, thanks
to Facebook's adoption of Open Graph:

http://developers.facebook.com/docs/opengraph

HTML+RDFa aims to standardize the use of RDFa in text/html, on top of HTML5
(which standardizes the parsing of text/html).

> > 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.

It's not necessarily safe to broaden semantics.

Imagine if your UA provided a menu command that would open up an email to the
author of the current page based on looking for an email address in the
"address" element.

If we broadened the definition to allow "address" to include any virtual
location, the UA could end up sending feedback to the email address of a person
who had no responsibility for the document.

Similarly, imagine you were aggregating citation and authorship information
across the web based on "cite" and "address". If you used "address" as the
source of your authorship information and we broadened the definition, you'd
end up with lots of false positive author attributions thanks to addresses of
people who were not authors.

Note these examples are purely illustrative of the dangers of broadening
semantics; I'm not saying any software actually does this or even that, given
the misuse of "address", that it would be feasible to do this in practice.

> And as I understand, the _original_ meaning did include my use case. It was dropped
> later on (I think on H3).

By my reading, the idea of author contact information was there from the start,
but the definitions did get clearer. At any rate, this has been the standard
definition since 1997.

> > 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.

Naming things is famously one of the hard things in computer science and lots
of things in HTML are badly named ("cite" was apparently meant to mean "work
title", many think it means "quotation").

If we were starting from scratch, I'd agree that "address" is a bad choice for
a name for this element. But now that it's been part of the language since 1997
(or earlier, depending on your interpretation), backwards compatibility trumps
better naming - all other things being equal.

All other things may not be equal in this case though.

-- 
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 19:05:49 UTC