It’s kind of redundant to post a “Get Firefox!” banner to someone already using Firefox, but it’s useful to show them an upgrade banner if they’re on an old version.  It’s also useful to show Firefox users a banner for Spread Firefox.

This can be done easily with PHP or other server-side scripting languages, but sometimes you have to use static HTML files.  That’s where client-side scripting becomes necessary.  Last month I posted some sample code that used document.write, which doesn’t work with XHTML.  (On top of that, the <noscript> blocks I used ended up causing validation errors because of their location!)

I’ve redone everything with DOM scripting, which will work with either HTML 4 or XHTML 1.0.

1. Put the following in a file called sfxlinks.js:

function replaceFirefoxLink(linkID) {
   if(linkNode=document.getElementById(linkID)) {
      var newLink=document.createElement('a');
      var newImg=document.createElement('img');
      var change=0;
      if ( 0 <= navigator.userAgent.indexOf('Firefox/0') ||
         0 <= navigator.userAgent.indexOf('Firefox/1.0') ) {
         newImg.setAttribute('alt','Upgrade to Firefox 1.5!');
         newImg.setAttribute('title','Upgrade to Firefox 1.5!');
      } else if (0 <= navigator.userAgent.indexOf('Firefox')) {
         newImg.setAttribute('alt','Spread Firefox!');
         newImg.setAttribute('title','Spread Firefox!');
      if(change) {
         var parentNode=linkNode.parentNode;

2. Use your regular Spread Firefox affiliate link and add a unique ID — let’s use id="FxLink" as an example — to the <a> tag.

3. Load the script in your document’s <head> section:
  <script type="text/javascript" src="sfxlinks.js">

4. Call the function in the body onload event using the ID you chose in step 2:
  <body onload="replaceFirefoxLink('FxLink')">

When the  page loads, the script will check the visitor’s browser to see if it’s an old version of Firefox or a current version of Firefox.  If it’s an old version, it’ll replace your standard button with your upgrade button.  If it’s a current version, it’ll replace it with a Spread Firefox button with your referral link.  Otherwise, it leaves the button alone.

This has a lot of advantages over the old version, including XHTML compatibility, no need for <noscript> blocks, easier validation, and it still degrades gracefully (if JS is unavailable or old, it leaves your normal button in place).

You can see it in action on my website, Flash: Those Who Ride the Lightning.

Originally posted on my Spread Firefox blog.

The new Opera 8.0.1 includes an experimental feature called Browser JavaScript. It’s a collection of client-side scripts that automatically corrects known errors on websites as they’re displayed. Opera downloads updated scripts once a week.

It’s an extension of the User JavaScript concept. Firefox’s Greasemonkey is basically the same thing, and it’s gotten a lot of attention as a method for correcting or enhancing sites. The key difference is that these scripts are centrally maintained, and automatically updated.

Browser JavaScript is disabled by default, and can be turned on by putting Browser JavaScript=1 in the [User Prefs] section of your opera6.ini file.

(via Opera Watch)

Pet peeve: Login forms that move the cursor to the username field AFTER the page finishes loading. Sometimes I’m already typing by then.

While working on a website for work, I inadvertently discovered why a web application I use frequently has the annoying habit of moving the cursor to the username field when I’m halfway through typing the password.

The basic way to set initial focus on a form field is to use JavaScript like this:


You can either embed it in the HTML after the form, or call it in the page’s onload() function. The problem with using onload is that it fires when everything is loaded, which means it waits for images, plugins, and so on. That’s very useful for some tasks, but isn’t the best choice here.

I’m impatient, especially with login forms. I don’t need the logos and background, I want to type in my username and password as quickly as possible and start using the app. Since this particular site isn’t exactly the fastest around, invariably the images don’t finish loading until I’ve started typing the password — and suddenly I’m typing the second half of the password in the username box.

Needless to say, I’m using the inline method on the site I’m building. Not that the login page has any images right now, but if I add any later on, it’ll save the users some aggravation.

Note: I’ve attached a 2009 tweet and the subsequent LiveJournal discussion to the original 2005 article.