g9g :: The oft-disjointed thoughts of Porter Glendinning

• Having far too much fun with the Echo Nest Remix API
• Apocalypsnow
• Duncan Edward Glendinning
• Turning the tables on the DiggBar
• Dueling Declarations: Following the Cascade
• CSS 2 Selector Fundamentals
• Flickr video
• When statistics attack
• Aidan Emery Glendinning
• Amazon thinks my son is a bastard
• I need a new phone
• Jason Lee must be stopped
• In case you hadn't noticed...
• Web standards, the three-legged race
• Ways not to wake me up

Turning the tables on the DiggBar

Updated Apr 21, 2009: Starting today Digg has revised the behavior of the DiggBar so that visitors to Digg-shortened URLs who are not logged in to a Digg account will be redirected through to the destination site instead of viewing the page with the DiggBar. Authenticated Digg users may also opt out of the DiggBar in their account settings. Over the last week or so there’s been a rather large kerfuffle in various circles regarding Digg’s execution of the DiggBar (No, I will not call it “Digggate”), with some, like Faruk Ateş, responding with conventional arms fire and others, like John Gruber, going for the thermonuclear option. Lidija Davis has put together a good distillation of things over on ReadWriteWeb, so I won’t belabor them here. I find my self more in line with where Eric Meyer seems to be on the issue — I don’t think the DiggBar is a great idea, but I find myself wondering where all this vitriol is coming from. This isn’t exactly a new concept, or even a radically new implementation. The most inflammatory thing the DiggBar does is to combine the creation of a short URL with their utility framing, which is almost certainly to blame for the visceral reaction. In response to a tweet from Eric yesterday asking whether anyone had come up with a way to prevent the DiggBar from usurping a page’s URL while not removing the DiggBar entirely, I whacked up this quick concept: De-DiggBar’ing a page’s URL while keeping the DiggBar It works by detecting that the page has been loaded via a DiggBar URL, bouncing the visitor back to the proper URL, and then injecting a short iframe at the top of the page that loads the DiggBar URL for the page. It’s far from perfect — heck, I even went with the quick-and-dirty doc.write injection. Ewww! One big drawback is that it actually causes your page to be loaded twice: once in the main viewport and again inside the DiggBar iframe. I was considering other methods of passing the DiggBar token through to the page that wouldn’t muck up the URL (e.g., via cookie value that could be removed upon reading) but didn’t bother. The massive failure with this approach is that the links in the DiggBar load within the iframe, rather defeating the purpose. The only way around that if you’re dead set on keeping the DiggBar available may well be either recreating the its capabilities in your own bar that’s inserted dynamically, or a server-side component that essentially proxies the DiggBar through into the body of the page.