Archive for the ‘programming’ Category

workaround for entity bug (?) in tabber

Tuesday, February 6th, 2007

A user of my tabber script discovered that when his tab headings had an ampersand character like this:

<h2>Me &amp; My Shadow</h2>

Then the tab control displayed “&amp;” instead of a single ampersand character.

It looks like this occurs because the JavaScript DOM function document.createTextNode() does not convert entities. However, it looks like innerHTML does convert entities, so to fix your problem find the following line in tabber.js:

DOM_a.appendChild(document.createTextNode(t.headingText));

and replace with the following:

DOM_a.innerHTML = t.headingText;

I’ll think about this some more and if I can’t find any bad side effects I’ll add to the tabber code.

How to beg

Wednesday, May 3rd, 2006
dog begging

I provide some free open source software, and to help defray the costs of this website, I usually beg for PayPal donations.

Here’s a JavaScript function I use, attached to the download link, to annoy people into sending me a donation:

function begForMoney()
{
  if (!arguments.callee.stopBegging) {
    arguments.callee.stopBegging = true;
    alert("Please donate!");
  }
}

Here’s how to attach it to a link. You can attach it to multiple links on the page, and it only triggers an alert the first time it is clicked.

<a href="" onclick="begForMoney()">Download</a>

Three more things you should not do in JavaScript

Tuesday, April 11th, 2006
see-no-evil.jpg

On the Yahoo! user interface blog I just saw their post “with Statement Considered Harmful“. Good advice.

Here are a few more things that I never do in JavaScript:

  1. Never use the “with” statement (as described above)
  2. Never use single line “//” comments. Use “/**/”. One day your code is going to be mangled and the newlines removed (perhaps by a crappy content management system), and suddenly your code will be commented out.

    Before:

    // a comment
    alert('ping!');

    After: (UH OH!)

    // a comment alert('ping!');
  3. Never omit the semi-colon after a statement. Again, this is to protect your code in case the newlines are removed, and to make the code easier to parse (by humans and machines).

    Before:

    var t = 'ping!'
    alert('ping!')

    After: (ERROR)

    var t = 'ping!' alert('ping!')

    This can be harder than it seems! For example, in the following example you should add a semi-colon after the closing brace:

    var myFunc =
    function() {
    alert('ping!');
    }
  4. Never omit the optional brackets { } around a statement. This can prevent some hard-to-debug errors when you add and remove code.

    Before: (MISLEADING INDENT!)

    if (true)
        alert('ping!');
        deleteItem();

    Fixed: (UNAMBIGUOUS)

    if (true) {
        alert('ping!');
    }
    deleteItem();

To check your code for missing semicolons and brackets, use JSLint.

Screencast: Diagnose a JavaScript Memory Leak in the Windows IE Browser

Thursday, March 30th, 2006
microphone

Here’s a new screencast:

Screencast: JavaScript Memory Leaks in the Windows IE Browser

This screencast by Patrick Fitzgerald of BarelyFitz Designs discusses how he diagnosed and fixed a memory leak in a JavaScript library. It’s a very simplified example, and the same techniques probably can’t be used for more complex web applications, but it might shed some light on how these memory leaks occur.

JavaScript-safe string variable

Monday, March 13th, 2006

If you have a bunch of funky data to store in a JavaScript string, for example some HTML, you have to be careful to “escape” all the special characters so it doesn’t break your script.

Or you can just use my web data encoder and choose “JavaScript-safe” variable:

web data encoder

You can also use other encodings, such as encodeURIComponent to make a complex URL safe to pass as a component of another URL.

Web Data Encoder for JavaScript-safe variables