HN does something similar. When you up/down vote something, it creates a new js Image object and sets the src to the HN site, which then pings the server. No need for ajax.

<code> var score = byId('score_' + item); var newscore = parseInt(score.innerHTML) + (v[0] == 'up' ? 1 : -1); score.innerHTML = newscore + (newscore == 1 ? ' point' : ' points');

  // hide arrows
  byId('up_'   + item).style.visibility = 'hidden';
  byId('down_' + item).style.visibility = 'hidden';

  // ping server
  var ping = new Image();
  ping.src = node.href;

</code>

Cool. Thanks for the code.

What's the advantage of doing it this way as suppose to using an ajax call?

Pro: You aren't subject to the same-origin policy that XHR has.

Con: You can't manipulate the Request (GET only, can't touch headers), and you can't even see the Response -- when you vote on HN it just increments the number it already had instead of getting the new number in the response from the server.

Simpler client-side code. Instead of setting up an XMLHttpRequestObject and forming a traditional POST request, you request a URL via GET.

If there's another advantage, I'm probably missing it (the image switchout shouldn't require a server-side call, since we already have the up/down icons loaded in the browser)

I doubt the code is that much cleaner compare to using framework (jquery) ajax call.

Maybe it's faster to do a "img get"? Or that you can't terminate it half way as suppose to an ajax? Better browser compatibility?

I haven't test it yet. I just hope someone who has can educate me.

For HN, I suspect the reason was that it was fast and easy to code. The main disadvantage in this case is that there's no actual guarantee that the request made it to the server, so if the request fails for any reason, it fails silently.

There are other advantages and disadvantages to image beacons depending on how you use them.

In the case of a search engine using them to track clicks, a major advantage is that the performance cost (to the user) of an image beacon is much lower than the performance cost of using redirect-based tracking. The tradeoff is that beacons are less reliable than redirect tracking, since users may not have JS enabled.

Also, with click beaconing, there's a race between the beacon request and the navigation event; you fire the beacon when the user clicks, but there's no guarantee that the request will finish before the browser switches navigation contexts, unloads the current page, and cancels all pending requests. An image beacon is more likely to succeed in this case than an Ajax request, since there's more overhead associated with Ajax requests.

All the major search engines use image beacons for tracking to some extent, but Google and Bing use them more than Yahoo! currently does.

Anyone want to fill in a non-web programmer on what pixel-tagging is?

Imagine that you want your web page to send a message "gphil clicked this link X" back to the server, but you're only allowed to request information, not gather it. The work-around that we use in web analytics, is that we request an image named "link-clicked.gif?dude=gphil&link=X." The query parameters are built dynamically with JavaScript and the image request is added as an on-click call on the link. The server is configured to accept this request and parse and log the data from the query parameters, and meanwhile returns a .gif image consisting of a single transparent pixel. This script apparently doesn't even render the pixel, it just stores it somewhere.

Advanced techniques include noscript fallbacks and adding a timestamp to prevent client or server caching from messing with your data collections.

That's pretty cool, thanks for explaining.

Keep in mind, because the image involves an http get request, the host of said transparent dot can also dump a cookie on you; this is how a lot of advertising agencies track conversions for cost-per-action ads. They tend to drop them for cost-per-click ads too, just to be extra annoying :)

Thanks. What's the distinction here: "but you're only allowed to request information, not gather it"?

No idea what pixel-tagging is but it seems they use javascript to load an image. The url of the image tells Google which link has been clicked on. There's some extra information in the url as well.

Bingo. Explained it a bit more in a comment: http://ryanangilly.com/post/355271652/how-google-tracks-clic...

I think it is just an invisible 1x1 image on your website, that is being served from Google. So everytime your web site loads, google gets a request for that pixel, including cookies and referrer.

As described here, I think they just trigger image loading from JavaScript to transfer information to the server.

Typically it's called a beacon, but wikipedia calls it "web bug": http://en.wikipedia.org/wiki/Web_bug

Here's another blog post with even more information on what parameters are being sent to Google during the click: http://www.razzed.com/2009/02/12/analysis-of-google-outbound...

If you are logged into Google, it sends more info using a different function

For Example: return rwt(this,'','','res','1','AFQjCNEdw7LJgOmjlxPAZ-jF7e3aPy1bbQ','&sig2=D3Wg-V0MDjmRS-gqjk66rA','0CAkQFjAA')

Did this just change or something? Earlier today I did a search and copied the URL and it was something like http://www.google.com/url?url=http%3A%2F%2F... But just now when I tried to duplicate it, I didn't get that. Weird.

With HTML5 this can all go away with <a ping=url ...>. :-)

you mean "with 90% adoption of HTML5 capable browsers AND a breaking change that prevents this from working", don't you ? :)