Month: July 2004

It’s all there in the title. But since your average Daily Mail reader probably won’t know what correlation and causation are I’ll lay it out in more detail. Person A plays violent videogames. Person A kills Person B. That’s correlation. Both things happened. It would be causation if the videogames caused the murder. Correlation (both happened) does not imply causation (one caused the other).

This concluded today’s lesson in common sense.

Cheah Chu Yeow mentions GooglePreview a cool new extension that places preview images beside Google search results. After a look at the code–isn’t open-source great?–he discovered that it gets the preview images from http://open.thumbshots.org/image.pxf?url=URL. Armed with this new information I threw together a bookmarklet to get a preview image of the current page: thumbnail. As always just drag the link to your bookmarks toolbar. It’ll open a new window with a thumbnail of the current page. I’m not too clear on what sites have thumbnails available and how to get your site included. As of now SoylentRed.net has no thumbnail available, but you can check it out on a more popular site.

Okay 48 Nobel laureates could easily be wrong, especially if they were literature laureates, but in this case they’re right. I’ve wanted to get away from my recent Mozilla-only blogging but I don’t think I can really say anything meaningful about this one. Just go read about how how

the [Bush] administration has sought to ensure the political fealty of scientific advisory committees; suppressed information on environmental damage from mountaintop mining; and doctored data to downplay risks to endangered species.

From the Center for American Progress.

Microsoft just launched a new marketing site for Internet Explorer in the guise of a team blog. Why do I say it’s a marketing site? Try this gem:

Some of us have our individual blogs today, but we also wanted to have one that was focused on what we do every day at work – make Internet Explorer the best way for browsing the web.

Compare this to what an actual developer blog should be: Surfin’ Safari is Dave Hyatt’s blog about Apple’s Safari browser where he has recently discussed Apple’s additions to HTML for Dashboard. This led to responses from other web-related proffesionals, including representatives of Mozilla and Opera who made suggestions to make these additions more palletable. Dave made swift changes to Safari’s implementation to address these concerns and continues to work with the wider community to ensure Apple doesn’t break the web.

Meanwhile Microsoft sits around patting each other on the back and saying how great their old and busted browser is.

Sometimes backronyms are really bad. Like BASIC. Someone decided "We need a language that sounds easy. Let’s call it Basic. But that sounds patronising. We’ll make up an acronym so it’s not as bad." I’m fairly sure I’ve discovered the worst one ever. Autosomal Dominant Compelling Helio-Ophthalmic Outburst is another name for the photic sneeze reflex, the reflex that causes many people, including me, to sneeze when exposed to bright light. Post your favourite backronyms in the comments.

I mentioned in the previous entry the "semi-functional comment-toggling that I started to work on quite a while ago and promptly forgot about". Well evidently I’ve remembered it (for some reason I typed that originally as "un-forgotten about it"; 1984 was 20 years ago). I’ve played around a bit and the following changes are of note:

• It now works in Opera as well as Gecko, after I eliminated the need for the addEventListener() function. It occurs as I write this that Opera claims support for this function so the problem probably lay in my use of window.addEventListener() as opposed to, I assume, document.addEventListener().
• It now only toggles the visibility of comments relating to the entry in which the toggle button was pressed, where it previously toggled all comments on the page.
• It’s possible to navigate to the toggle with the keyboard. I’ve made it an actual link so that it takes a place in the browser’s tab order. Previously it was an image with a javascript onclick attribute and some CSS making it look clickable.
• Since the code now works properly in the browsers it works in and fails gracefully in those it fails in—ie. it isn’t visible at all to browsers that can’t handle it, like Internet Explorer—I have made coments invisible by default. The new comment icon will only appear if there are comments on the entry. Clicking on it will display them immediately since they’re already downloaded. Comments remain visible at all times on browsers that can’t handle this code.

Personally I think this is a pretty good example of additional functionality made available to those who can support it without any side-effects for those who can’t.

Given that I’m not a Christian I’m free to fully appreciate icons. I’ve thrown together three new icons for SoylentRed, a permalink, a comment and a site icon. Each is a 16 × 16 semi-transparent PNG. You may need to refresh in order to see them.

The comment icon is used for the semi-functional comment-toggling that I started to work on quite a while ago and promptly forgot about. It’s only visible to users of Gecko-based browsers (which is about 90% of my visitors).

Update: I’ve also created an icon for post a new comment. Again you’ll have to refresh to get rid of the ugly red border.

After my recent announcement of the release of version 1.2 of MakeLink it became clear that there was no intuitive way of installing the extension. While I promptly offered an excuse and a workaround I haven’t, until now, offered any form of fix. The problem was that I had simply linked to the .XPIs and relied on the Firefox to be able to determine what type of file it was being given. More accurately I was relying on the server—in this case netsoc’s server which I still use to host these files, out of habit—to tell Firefox what type of files it was sending. The server, not having been configured for this use, had no idea. Consequently Firefox had no idea. Therefore, unless the user—who can never be relied on—had some knowledge of the transactions going on, the result was a clueless browser asking a clueless user what to do with a file served by a clueless server. Step in the cluefull developer to the rescue.

It turns out there are better ways to hold this whole process together. Ways that don’t rely on servers or users knowing what’s really going on. Ben Goodger, lead developer of Firefox, posted a guide on mozilla.org on Installing Extensions and Themes from Web Pages. The guide asks that developers use the method described to install extensions and themes because it "provides the most seamless experience to users". It may very well provide a seamless experience but it is not without problems. One, it’s not generalised—it requires seperate scripts for each extension or theme you want to serve. Two, it requires invalid HTML. (It’s also missing a closing brace but I don’t count that as it’s a simple typo.)

Ben’s solution is to present a link like this:

<a href="http://www.foo.com/bar.xpi"
  iconURL="http://www.foo.com/bar.png"
  onclick="return install(event);">Install Extension!</a>

which calls a function install() defined by this:

function install (aEvent)
{
    var params = {
    "Bar": { URL: aEvent.target.href,
             IconURL: aEvent.target.getAttribute("iconURL"),
             toString: function () { return this.URL; }
    };
    InstallTrigger.install(params);
    return false;
}

The lack of generalisation comes from the function itself, where the name of the extension is hardcoded ("Bar"), making it impossible to use the same function for more than one extension. You would need one copy of the function for each extension you wanted to deliver—installFoo(), installBar() etc. with a single line altered in each. To be honest the generalisation aspect wasn’t of major importance to me since I have only one extension to worry about. But the invalid HTML—the made-up attribute iconURL—is not something I want to see when Firefox is the most standards-compliant browser in the world. So I set out to replace Ben’s approach with my own. I placed three requirements on my replacement:

• That it be generalisable to any number of extensions.
• That it only use valid HTML.
• That it retain the "seamless experience" that Ben wanted from his original.

None of these requirements are negotiable.

My first attempt was simple. I removed the iconURL attribute from the link and made it an extra parameter of the function:

function install(aEvent , iconURL)

, changed the line that determined the icon URL from the link’s attribute so that it simply adopted the value passed to the function:

IconURL: iconURL,

, and made sure the link had the extra parameter when it called the function:

<a href="http://www.foo.com/bar.xpi"
  onclick="return install(event,'http://www.foo.com/bar.png');">Install Extension!</a>

That took care of the validity issue neatly, but left the generalisation issue unresolved. The obvious step was to do something similar with the name of the extension as I had done with its icon URL, that is to add another parameter to the function specifying the name of the extension. So I ended up with this function:

function install(aEvent , extName, iconURL)

{
    var params = {
      extName: {
        URL: aEvent.target.href,
        IconURL: iconURL,
        toString: function () { return this.URL; }
      }
    };
    InstallTrigger.install(params);
    return false;
}

which was called by this link:

<a href="http://www.foo.com/bar.xpi"
  onclick="return install(event,'Bar','http://www.foo.com/bar.png');">Install Extension!</a>

This seemed reasonable. All I did was replace a literal string ("Bar") with a variable that refered to a string. Unfortunately the result was a dialog that presented the name of the extension as "extName". That’s not a solution at all. I consulted the nearest reference I could find on javascript, the Core JavaScript Guide on DevEdge. About the first thing it mentions about objects in javascript is the remarkable reature that an object and an associative array are the same thing. That meant I could define the object params as an empty array and then assign the actual parameters object to an element of the array who’s name was determined by the value of the name parameter. The end result is this script:

function install(aEvent, extName, iconURL)
{
    var params = new Array();
    params[extName] = {
        URL: aEvent.target.href,
        IconURL: iconURL,
        toString: function () { return this.URL; }
    };
    InstallTrigger.install(params);
    return false;
}

This fits all of my criteria for a useful replacement of Ben’s version without adding any complexity. I use a simplified version of this script—I don’t use iconURL since MakeLink has no icon—to make installation of MakeLink about as easy as it could reasonably be expected to be.

Updated 17 May 2005: I fixed the code as per the comments. Sorry for the delay.

Asa’s asking everyone who uses and likes Firefox to take action and help spread the word about how great it is. Specifically he wants you all to leave reviews on the Firefox listing on Download.com. The aim is to get 1000 new reviews in a week. The updates here and here say we’ve had 500 in the first two days.

If you’re concerned about privacy—or just too damn lazy to register—use the username ‘abcdef123456@mailinator.com’ and the password ‘password’ to log in. Thanks to BugMeNot.com.

MakeLink is by far the most popular entry point for this site so I think it’s only fair that I devote some time to it. I’ve just released version 1.2 which addresses a few issues with previous versions. This new version and all future versions will only work for Firefox 0.9 and later. If you’re still using 0.8, well why?

Two new features were suggested by Brian Lalonde: HTML links are now copied as text/html so they can be pasted into word-processors and email clients that support HTML and there is now an option to retain title attributes when copying HTML links.

Along with those two features there were two bug fixes, described on the project page, and there’s a new ‘About’ box. I’ve had some more ideas for extended features while fiddling around with the code so expect a 1.3 version to be forthcoming.