[whatwg] <a href="" ping="">

[James Graham]

Lachlan Hunt wrote:
> J. Graham wrote:
>> On Sat, 22 Oct 2005, Lachlan Hunt wrote:
>>
>>> It could be defined in reverse, where the ping attribute (probably 
>>> given a more suitable name, but I'll use ping for now) could be 
>>> advisory information about the final destination and the href 
>>> attribute defines the ping destination, such that following the href 
>>> attribute would perform a redirect, but WA1 UAs could use the URI in 
>>> the ping attribute to notify the user of the final destination (such 
>>> as displaying it in the status bar).
>>
>> <a href="scamsite.com" ping="ebay.com">
> 
> <a href="http://scamsite.com/">Ebay.com</a>
> 
> What's the difference?

In one case the status bar reveals the true location, in the other case 
it doesn't.

> 
>> Sure it's not much in the face of an alert and savvy web user but 
>> there's a reason channging the status bar via js can be disabled (is 
>> it disabled by default?)
> 
> Sure, scams are always a risk.  It could be defined that if the location 
> returned with the redirect does not match that in the ping attribute, 
> that the user should be immediately notified of the deception.  For 
> legitimate cases, where the href is merely a redirection to the final 
> destination, the user will get there without any problems.

So why not enforce this case by making the client do a redirect as soon 
as it receives a response from the original URL:

<a href="tracker.cgi" redirect="destination.html">

On receiving a response from tracker.cgi the client would redirect to 
destination.html, irrespective of the contents of the response. It would 
allow the correct destination to be displayed in the status bar which, 
as far as I can tell, is the only merit of the original 'ping' proposal, 
but still has the disadvantage that no-one would use it (since a UA 
could easily disable contacting tracker.cgi,  making it useless for 
advertisers). It does, however,  have a reasonable backward 
compatibility story (tracker.cgi would typically take a URL parameter 
which it would redirect to). The big problem is that it seems horrible 
to implement, as one has to have special handling at the network level 
for requests initiated from a link with a redirect attribute.

-- 
"It seems to be a constant throughout history: In every period, people 
believed things that were just ridiculous, and believed them so strongly 
that you would have gotten in terrible trouble for saying otherwise."

-- http://www.paulgraham.com/say.html