Archive: March, 2005

So, do I go to @media?

What with having to register today in order to get the early bird discount to @media 2005, I've been weighing up the options.

Some of you may have noticed the text in the sidebar becoming less optimistic about going. It's mainly down to finance… isn't is always?

As a self-employed guy/a freelancer/whatever and coming up to the end of my first year of trading, it's been a busy time and budgets have been tight. Although, that's probably also true outside of the first year. 🙂

£345 + VAT is quite a lot for a conference. But Patrick Griffiths has organised a great event, which is going to be right here in the UK for a change! It will be a fantastic opportunity to learn from and meet some of the people I've only been in touch with on forums or by e-mail or spoken to on the phone.

So, it's a trade off:

  1. Don't go, have more money to be able to keep paying myself, miss out on kneeing someone in the nadgers and all the fun and games… I mean, learning and networking. Or;
  2. Go, have less money in the kitty, work harder later to make up for it, meet lots of people, learn a few things along the way.

What do people think? At the end of today, I could always work a little bit harder to get anough to pay the full registration cost, but there's also the fact that places at the conference are limited and selling out from the sounds of it.

Where’s Durstan?

OK, I wasn’t going to get involved with this, but after catching up with all the malarkey (!) at lunchtime, I couldn’t resist.

A quick Google Image Search for “Durstan” picked up some interesting images, and having been kept updated with SxSW 2005 via Flickr, I couldn’t resist using this photo by Richard Rutter.

Where's Durstan?

Credit where credit’s due


Jo decided to get in on it as well with this one: Can you find Durstan in this maze?

Blagging Bookmarklets

OK, having not had so much time recently to play with bookmarklets, I finally came to the conclusion that I wasn’t going to be able to finish this post as I first intended. As a precursor to developing some Firefox extensions, bookmarklets was never going to cut it anyway. I just wanted to brush up on some JavaScript – I’ve been spending more time working on developing my skills in accessible design than with my geeky programming roots. Anyway, I’m yet to do anything even remotely complicated with bookmarklets, but I thought I’d share what I’ve been up to recently.

WDG Validator

Rich Pedley (a.k.a. Elfin) got in touch with me to solve a little problem he was having using the WDG validator to validate documents that have a custom XML DTD. You need to add “xml=yes” into the URL for the validator as it doesn’t give you the option on the website. Rich wanted a bookmarklet that would do this for him, so this is what I knocked up:

Older browsers may not understand the encodeURIComponent() function, so you might need to use escape() instead.

Personally, I’ve preferred to add these validation tasks as tools on the Web Developer extension toolbar, as I tend to use that for much of my day-to-day meddling on the Web.

Check highlighted word

OK, here’s a handy one: a spell checker for individually selected/highlighted words. I wanted to be able to check the spelling of words in a post before I sent them. I was originally inspired to write a Firefox extension for this, but I wanted to try a bookmarklet first. The thing is, you can’t actually do what I was trying to do with a bookmarklet. You cannot identify which textarea element on a page has focus. The JavaScript in a bookmarklet is run after a page has been rendered and after any events occur on the page, so there’s no way to add a listener for focus events. Feel free to prove me wrong.

Anyway, I did come up with something. The following bookmarklet checks the spelling of highlighted words in every textarea element on a page. If you select more than one word in any textarea element, it will only check the first word in the selection. It won’t do anything unless you have selected some text.

The problem with this is that if more than one textarea element has some highlighted text, they all get checked. This is why I wanted to detect which textarea element had focus. I did try offering the option to choose which word to check when more than one textarea element has a selection. The code for this got rather long, breaking the 255-character limit allowed for bookmarklet code. It’s possible to use a bookmarklet to send information to an external JavaScript file hosted on a server, but that just seems a little over the top for something so simple.

So, at this point I was back to my original plan: write a Firefox extension. You can easily add this sort of thing to a context menu. However, a good Google goes a long way. I found that someone had already done what I wanted to do. In fact, several people had. In the end, I decided that I would try my hand at writing my own extension anyway, but I’ll save that for a future post.

Creating your own bookmarklets

Here are a couple of pointers that I’ve found useful while playing with bookmarklets.

If you’re making your own bookmarklets, you can use whatever JavaScripts works for you, but you should really try to use JavaScript that works in most browsers. For example, you should avoid using proprietary methods and statements such as document.all. Also, some older browsers don’t like some of the newer methods. For example, as I mentioned earlier, instead of using encodeURIComponent() to encode a URI, you may need to use the older encode() method instead.

Another thing to watch out for, when using XHTML sent as application/xhtml+xml, you should be using createElementNS() and not createElement() as you would for any document sent as text/html.

A common thing for a bookmark to do is open some information about the current page in a new window (for example, using open()). It should be noted that the name you give to the window should not have any spaces or other special characters in it. Firefox et al won’t care about it, but IE will throw an error and your bookmarklet won’t work. It might seem a simple thing to point out, but it can be a difficult error to debug… this will save you some head-banging.

For example, the following two lines won’t work in IE:

open('','Dotjay blog','resizable=yes,width=700,height=500')

You must use something like this:


Also, check out the “Crunchinator” – an online tool that will take your normal JavaScript formatting and remove all the crap you don’t need to give you a single line of JavaScript suitable for your bookmarklet.

Getting a good blogging

After writing most of these posts on bookmarklets, I got up-to-date with some blog reading and found that Gez has been discussing the creation of bookmarklets recently too! He goes more in-depth into creating a bookmarklet that will allow you to load a custom style sheet into the head of a document.

I also notice that Andy Budd has a list of useful bookmarklets he uses.

Add “Validate Entire Site” to Web Developer Extension

It’s pretty easy to add a tool to Chris Pederick’s Web Developer extension that will spider an entire site and validate it for you. The WDG validator (which the Web Developer extension doesn’t use by default) will do this for you if you add the right options in.

To add “Validate Entire Site” as a custom tool

It’s quite straightforward really. You just need to create a new tool in the Tools options (version 0.9 and up, I think) and make sure &spider=yes is in the URL for the WDG validator. Just follow these steps:

  1. Select “Options…” from under the “Options” menu in the toolbar.
  2. Find the “Tools” options.
  3. Add a new tool by using the “Add…” button.
  4. Enter the tool description (I use “Validate Entire Site”).
  5. In the URL field copy and paste this: The URL of the current page in the browser window will be appended to what you enter here, so the &url= must be at the end of this line.
  6. Optionally, you can also add a keyboard shortcut for this tool, so that you can validate an entire site with Control+Shift+[key].
  7. Hit the OK button to save your new tool.

Important! Please note the updates below. There are a few limitations with using the WDG validator for this tool.

To validate a page or an entire site with a custom XML DTD

By default, the Validator assumes that a custom DTD is HTML or SGML. If your custom DTD is XHTML or XML, then you need to include the Validator’s hidden “xml” option. When validating a URL, you can specify this option by appending “&xml=yes” to the URL of the validation results. WDG HTML Validator Tips

So, this would mean that you need to add &xml=yes into the URL for your tool.

For validating a single page with a custom XML DTD:

For validating an entire site with a custom XML DTD:


15 February 2006

This article is proving fairly popular, so I thought I’d add a couple of useful links to this tip.

30 March 2006

It’s also worth noting that the WDG validator limits its spider to checking the first 100 pages it finds.

09 July 2006

You may find that the WDG validator only validates one page if you use this tool on a page within the site you wish to validate. Use the tool on the main domain (e.g. rather than to get the validator to spider the whole site.

24 August 2006

Someone asked about validating password-protected sites. The WDG validator does allow you to validate pages behind HTTP authentication, but you must provide the username and password in the URL. The validator cannot spider a site you are already authenticated on – you must provide access details in the URL.

The Web Developer toolbar gets around this for individual pages by either asking you for access details when trying to validate a password-protected page or allowing you to use “Validate Local HTML, saving a local copy of the page and uploading that for validation.

When adding custom tools to the Web Developer toolbar, you don’t have the means to trigger a request for access details. To validate an entire site which is password-protected, you need to ensure that the username and password is entered as part of the URL.

27 March 2007

I’ve just noticed that you can also add &hidevalid=yes to the URL to get the validator to hide the valid results it finds for your site, making it much easier for you to find problems!

This Burdensome Blog

I've been trying to figure out why my textpattern run time has been so slow. I'm trying to get to the bottom of it, but in the meantime, my apologies to readers.

I've probably buggered something up while adding in some of my tweaks or installing a plugin somewhere. I'm taking off a couple of features that I think might be causing problems while I'm working on them.

Also, I'd just like to quickly thank vigo, who helped me find one problem that was slowing things down a bit: textpattern's logging script does a DNS lookup so that it can log host names rather than just the IP address of referrers. Moving this lookup into the back-end slows things down for me rather than you lot.

Quick Guide to Bookmarklets

Recently, I’ve been playing around with writing Firefox extensions to add toolbar buttons that allow me to add a couple of simple tools I’d like to see on my toolbar. More on that soon, but in the process I’ve written a couple of bookmarklets to test some of my ideas. So my next couple of posts will be about bookmarklets. Here’s one to get started.

First of all, I call these things “bookmarklets”. I use Firefox for my main browser, which has a bookmark manager. Most people will be familiar with the Favorites menu/folder/sidebar in Internet Explorer. I never even used Favorites when Internet Explorer was my main browser, so they’ve never been “Favelets” to me.

Bookmarklets have been around for a long time. They are simple JavaScript programs that you can activate as you would a bookmark, making them quite handy tools. These are especially handy when your browser doesn’t let you add custom buttons to your toolbar.

Web designers and developers in particular started using them to make frequent tasks easier. For example, you could program one to resize your browser window to a variety of screen resolutions. Some designers still use bookmarklets for such tasks. Personally, I use Firefox with Chris Pederick’s Web Developer toolbar or Internet Explorer with the AIS Web Accessibility Toolbar which cover many of my common tasks. Other bookmarklets can help general browsing. For example, Movable Type uses bookmarklets to make it easy for you to publish to your blog when you stumble across something that inspires you while browsing.

How to use bookmarklets

Bookmarklets will usually appear on pages as hyperlinks like those that trigger some JavaScript. You save a bookmarklet to your Bookmarks (or Favorites) in the same way you would a normal link. You can drag and drop the link into your Bookmarks or hit “Bookmark This Link” (“Add to Favorites” in Internet Explorer) in the context menu of the link you want to save. Internet Explorer will usually give you a warning message when you try bookmarking a JavaScript link, but don’t worry about it.

Once you’ve saved a bookmarklet, you can access it as you would a bookmarked website. When you’re on a site on which you want to perform the bookmarklet code, go to where you saved the bookmarklet and hit it. It will then perform its JavaScript magic on the site.

I can’t write no stinkin’ bookmarklet!

Steve Kangas’ has a vast library of bookmarklets to get you started, and our good friend Tantek Çelik has a few favelets. Also, those Web developers out there who haven’t yet heard of the slayeroffice Favelet Suite really should go and check them out.

More to come

I’m no JavaScript guru, but I know enough to get by. I have created a couple of bookmarklets recently and it really wasn’t all that difficult, so I’m going to write soon about how I did those. In the meantime, check out the bookmarklets I created to help Elfin over at permanent tangent and the GAWDS Site of the Month nomination bookmarklet generator (what a mouthful).