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

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

--- Comment #6 from arieh glazer <arieh.glazer@gmail.com> 2010-12-16 19:29:05 UTC ---
(In reply to comment #5)
The href:geo specs look really cool, and I am already on my way to implement it
on some of my projects. But as you say, it is far from generic and it is in no
way easy to embed in dynamic content generators (such as CMSs), comparing to
the address tag. 

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

All popular browsers nowadays do not do much on any element other than style it
(putting anchors and form elements aside). As I understand, H5 is a lot about
creating a better semantic markup (most added elements have not style). 
The only important part IMO is that out of the box, this will not break browser
behavior even a bit.

> > 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).
> 
I have not been aware of this. Last time I stumbled uppon RDFa it required
text/xml+html for adding more namespaces (which broke IEs). 
I am aware that H5 brings together a lot of good and rich solutions for a very
wide veriety of problems via MD and RDFa. 
My thoughts were about fixeing what I understand as a problem in a definition,
by adding more use cases to an existing element.

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

I accept the above is a valid reason for not fixing the problem, but IMO this
should at least be checked. If the change does create a breaking change for
various software, it will be a reason for not accepting my suggestion. 
But, as you say yourself, this change is already in use (be it non-standard)
and thus the change won't "break the web" any more than it already is broken.

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

There have been other changes to the specs that changed the semantics of other
elements - such as b and i - which, if implemented by generic software would
create a much larger problem than adding more definitions to the address tag. 
(if it is not clear - my point is that the case s valid, not that the above
shouldn't be touched, as I am sure a lot of discussion was done on the above
mentioned topic which I am not very familiar with).


> 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").
> 
> All other things may not be equal in this case though.

Name alone is indeed not a valid reason. I believe I have made my point in a
way that exceeds naming.

-- 
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:29:08 UTC