I’ve just played with an idea for a wordpress plugin. If you download this plugin and install it you can use the following syntax for links in your posts:

[link:url,text,xfn data]

The plugin will then check if the url exists and create a link if it does or otherwise add a DEL element with a class called “brokenlink”. The xfn data is optional and there is no testing as of yet. In order to make them work you need to use the valid XFN data values.

Tests:

• My Articles (http://icant.co.uk - me XFN)
• My scripts (http://onlinetools.org - me XFN)
• Drew McLellan (http://allinthehead - friend met co-worker colleague XFN)
• Offlinetools.org (should be broken)

My inspiration

The inspiration for this was Tom Croucher’s talk at barcamp London about the self healing web. Read more about it on his blog.

Over the last few months there were more and more requests on mailing lists and articles published how you can achieve functionality with pure CSS that was traditionally achieved with JavaScript. This post will explain why that is an interesting concept, but hopefully make you aware of the benefits of JavaScript enhanced solutions versus pure CSS solutions.

I have to thank a lot of people I asked in the research for this, foremost James Edwards, John Resig and Andrew Dupont. I’ve also given a short presentation - PDF -96KB on the same topic at the Barcamp in London last weekend.

First of all let’s investigate how pure CSS solutions became so popular. (more…)

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.

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.