[whatwg] Current status of hyperlink authoring (a.k.a. the ping attribute) and some suggestions

Ronny Orbach r at ronnyo.com
Wed Apr 27 14:36:59 PDT 2011


Hey Jukka, thanks for your insightful reply :-)

Sure I've meant hyperlink auditing.
As for Chrome, I reckon it doesn't count these requests as part of the
tab process and therefore doesn't show them in the developer tools.
One can argue with that decision. Anyway, they're visible via Fiddler
and the like.

Speaking of Chrome, just today I've stumbled upon something very
similar - Their 'prevent this page from creating additional dialogs'
feature cannot be detected. This means a confirm dialog will always
return false without showing up - Which actually breaks stuff in a way
that cannot be repaired because of this behavior. I say, if you
already implement something, provide some transparency into it.
Without proper feature detection even the bravest idealists won't be
able to use this.

I agree with most of your answers. Oh well, yet another interesting
case of a doomed feature.

Cheers,
  Ronny


> Date: Wed, 27 Apr 2011 07:52:59 +0300
> From: "Jukka K. Korpela" <jkorpela at cs.tut.fi>
> To: "whatwg" <whatwg at whatwg.org>
> Subject: Re: [whatwg] Current status of hyperlink authoring (a.k.a.
>        the ping        attribute) and some suggestions
> Message-ID: <C8FF46C4EA08427D90AD6D96E5CC9F2E at JukanPC>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>        reply-type=original
>
> Ronny Orbach wrote:
>
>> I've researched hyperlink authoring
>
> You seem to mean hyperlink _auditing_, specifically using the proposed
> ping="..." attribute.
>
>> which IMO is a great feature,
>
> To me, it seems that it mostly generates the types of problems that it is
> supposed to solve.
>
>> and it looks like the only browser which
>> implements it today is Chrome
>
> As an aside, when using Chrome debugging mode, the "Network" pane shows no
> request corresponding to the ping attribute, and no POST request whatsoever.
> This might be just a bug^H^H^Hfeature in Chrome debugger.
>
>> Not sure why implementation and buzz around this are so minor
>
> Apart from lack of practical need and apart from obvious problems, you mean?
> :-)
> The attribute seems to do nothing that could not be done using existing
> other techniques. While it superficially makes "hyperlink auditing" easier
> to authors, who would use it? If it is something that can be easily disabled
> by users, why would it be used, instead of current methods?
>
> The advantages listed at
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#hyperlink-auditing
> are theoretically good-looking from the educated user's perspective. But
> site administrators and advertizers have a completely different perspective.
> Besides, most users would just get confused with the issue if they were told
> about it.
>
>> If authors can't be sure ping will work,
>> they won't use it.
>
> Indeed.
>
>> However, regular feature-detection or UA sniffing
>> won't suffice because the user can disable the feature*. So ideally,
>> we could have a boolean property like Navigator.features.ping, so we
>> could do if(!Navigator.features.ping) runPingShim().
>
> Why would we introduce a feature for the sake of giving users the control,
> then develop methods for defeating that control because authors wouldn't use
> the feature otherwise? And they won't use it anyway, as it's much simpler
> and safer to keep doing what they do now.
>
>> No one will use a
>> ping-system which freaks out users and tells them they're being
>> tracked.
>
> Well, no one except a few idealists - a far too small population of authors
> to be considered seriously.
>
> --
> Yucca, http://www.cs.tut.fi/~jkorpela/
>



More information about the whatwg mailing list