Via Stuart Colville I got a URL that uses a sneaky trick to see where you have been surfing. Jeremiah Grossman shows how you can check for visited sites.

The common complaint of developers who don’t see the security and privacy issues with that is that you can read out the history of the window with JavaScript but you only get the amount of visited sites, not their URLs. With this trick, you can.

The trick is pretty easy: He uses a whole array of sites to check against, writes out a style for visited links to the page, writes out a list of these links and checks their computedStyle color attribute against the colour he set in the style. If it is the same, the page is in cache and has been visited beforehand.

I already commented that it may be more stable if you set a different style to the visited links like display block and a height and read the offsetHeight instead of computedStyle. In any case, it is a clever and worrying trick.

Being bored yesterday night, I thought that it would be really cool to have a flickr badge that can be navigated (x pictures forward and backward), has a preview in middle size mode (lightbox style) and is generally nicely unobtrusive.

I cobbled together some code (dirty at times) and came up with this: Unobtrusive Dynamic Flickr Badge.

What it does is turn a simple link to your Flickr stream with a certain ID into the badge, which means that users without JavaScript can still reach your images and you don’t need a server component to pull the images.

And guess what, it is not even Ajax!

Tell me what you think, and I may find some more time to spice it up with the YUI and make it cleaner.

The August issue of Practial Web Design is out and features an article of mine about creating plugins for Yahoo Messenger.

When I was creating a proof of concept the other day about how to create ‘more content’ links with JavaScript and the YUI I stumbled across an interesting problem with the YUI Event utility.

The Event Utility is IMHO the cat’s pajamas as it solves a lot of issues the tried and true addEvent didn’t: It retains the scope allowing you to use “this” in the listener method, makes preventDefault work in Safari and also allows you to send another custom object to the listener method, all of which make is a lot easier to write unobtrusive JavaScript without the memory leaks.

Now, the interesting problem I stumbled upon is that if you do the following

• create a new link
• add attributes, content and all that jazz
• apply an event handler
• clone the link
• apply another handler to the second link

you’re in for trouble. Safari applies both handlers to the first link and none to the second, and MSIE applies both the first and the second handler (in reverse order) to the second link! Here’s the test case using YUI. The MSIE problem of the double handler on the second link also happens when you use the tradional addEvent.

I talked to the YUI folks and Adam told me that applying unique IDs to the links solves the issue in Safari, however it doesn’t make a difference in MSIE.

The lesson to take away:

If you clone elements, make sure to clone them before you apply the handlers, and remove all handlers just to be on the safe side

A shame, as I really like the idea of cloning elements. The other option of course is a constructor method for repeated elements.

I have my personal “Walk Like a Pirate Day” today. Somehow I managed to strain my knee on Friday and Saturday it felt bad but Sunday it felt terrible. One hour waiting in the NHS Centre later I got the amazing advice to “take some pain pills and we’ll see how it is on Friday. If it is not better, go to your GP” (for more waiting, I suppose).

All in all this leaves me with a Clouseau-worthy limp and I am tempted to go Arrrrrrr me mateys! to get a seat on the tube.