That’s not good. Yes, jquery is lightweigt, CSS files aren’t big, but that’s not a good reason for making every visitor download them. I did some research and it doesn’t look like anybody wrote about a solution yet, so here’s one way. Usually, you would add an action to wp_print_styles or wp_print_scripts that does something like this:

add_action( 'wp_print_styles', 'yourplugin_include_css' );
 
function yourplugin_include_css() {
    echo $csslink;
}

Instead, try this:

add_action( 'wp_print_styles', 'yourplugin_include_css' );
 
function yourplugin_include_css() {
    // Check if shortcode exists in page or post content
    global $post;
    if ( strstr( $post->post_content, '[yourshortcode]' ) ) {
        echo $csslink;
    }
}

That’s it. Please don’t add custom javascript or CSS on each and every page of my blog.

Update: See this excellent post for an improved solution.

Update 2: The best solution for loading JavaScript so far

Usability

Tab Kit: My favorite tab extension. Has many many features, I use it mostly because it allow more than one row of tabs and tab grouping/collapsing.

Clear Fields: This solves a quite annoying issue with Firefox and the xorg clipboard. Xorgs lets you paste things that you have highlighted with the mouse by simply clicking the middle mouse button. However, the previous contents of the search and address fields don’t get cleared. This adds buttons to clear those fields before pasting.

Development and Webdesign

Firebug: The swiss army knife of web developer add-ons. To quote from it’s description: “You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page”. Very power- and useful.

Gridfox: Indispensable while making grid-based layouts or aligning text to a base grid.

Live HTTP headers: This is rather esoteric, but very useful for JavaScript debugging and web app development.

Web Developer: This is what I used before Firebug existed, and it’s still useful today.

MeasureIt:This is very useful for quickly measuring the size of various elements on a page.

Privacy/Security

Cookie Monster: The best cookie manager I could find. I always block all 3rd party cookies, and by default no website is allowed to store cookies on my computer. Cookie monster makes it very easy to allow cookies for sites I visit. Another nice feature is to only allow session cookies for some sites.

Flashblock: Blocks all annoying flash animations. Can whitelist sites of course. A must.

NoScript: Blocks all (3rd party) JavaScript. Indispensable security tool and gets rid of most ads as well.

There was a time when websites used “Best viewed in Internet Explorer” or “Best viewed in Netscape” kind of texts and banners. Some sites even blocked you if you were using the ‘wrong’ browser (it still happens today). That was stupid in the 90s, and locking out IE6 isn’t any smarter today.

If you want to behave like the “Best viewed in Internet Explorer” crowd of the 90s just go ahead. There was a different movement back then that still exists today: Viewable With Any Browser. There’s really no need to punish some minority browsers.

Anyone who slaps a ‘this page is best viewed with Browser X’ label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network.

Tim Berners-Lee in Technology Review, July 1996

I guess I’ll just go on and build sites that are more or less standards-compliant and hopefully don’t require special tweaking for IE6. There are enough cross-browser tools out there. Just use your favorite search engine to find JavaScript libraries, CSS frameworks etc. Of course, something will always break in the old IEs, but don’t waste time breaking it on purpose.

Update: Just found this gem from the gif-crazy 90s and had to add it:

#foo {
    border-radius:          8px 4px 4px 8px;
    -moz-border-radius:     8px 4px 4px 8px;
    -webkit-border-radius:  8px 4px 4px 8px;
    -khtml-border-radius:   8px 4px 4px 8px;
}

No browser seems to support the first notation yet. That’s fine as CSS3 isn’t complete. However, mozilla, webkit and khtml-based browsers should be ok. IE and Opera will just ignore those.

The syntax differs in some details though, see for example:

    -moz-border-radius-bottomleft:      5px;
    -webkit-border-bottom-left-radius:  5px;

Oh, and Safari doesn’t seem to support a radius given in percent, mozilla does:

    -webkit-border-bottom-left-radius:  10%;

This doesn’t work for me in Safari.

By the way, this blog’s wordpress template uses CSS3 border radiuses. Hi IE users

Update: This post led me to Drew Diller‘s blog. He has an interesting technique for rounded corners in IE. Another technique by Remiz: see other technique for rounded corners in IE. Who knows, maybe I will be able to deploy sites that use border radiuses in the future, even if Microsoft has no plans for supporting them in IE8.

It’s good to know which features the users use, how often, in what order etc. Do you need to advertise some functionality more? Maybe you need to prepare better documentation so that they even know how or why to use some things?

If you have outgoing links, you may want to know where your users are going? The ugly way of doing this would be to use some sort of redirect URLs and monitor those. But I don’t like that way. If I use mootools anyway I can track outgoing links more elegantly. And redirects certainly can’t handle ajax stuff.

1
2
3
4
5
6
7
8
9
10
11
12

function clicktrack(id) {
    var elements = $(id).getElements('a');
    elements.each(function(item, index) {
        $(item).addEvent(
            'click', function() {
                new Image().src = '/usability/?click='
                + $(item).getParent().id + "&" + $(item).id;
            }
        );
    });
}
clicktrack('mode');

Add a HTML that looks somewhat like this to get an idea what buttons your users are clicking.

1
2
3
4
5

<div>
   <a id="1" href="#">option 1</a>
   <a id="2" href="#">option 2</a>
   <a id="3" href="#">option 3</a>
</div>

Of course, in an ideal world, you’d want to offer non-JavaScript links too. Tracking outgoing links is even simpler, i’ll leave it as an exercise for the reader

So inside the domready event I simply did:

1
2
3
4
5
6
7
8
9
10
11
12

function inputify(elem) {
    elem.focus();
    elem.addEvents({
        'keydown': function(event) {
            if (event.key === 'backspace' && !elem.value) {
                history.back();
            }
        }
    });
}
 
inputify( $('SomeInputfieldById') );

Great, reusable, everthing works fine. Ok, so let’s incorporate my ideas from my HTML forms and onclick/onfocus post (basically, select on click instead of focus and pre-fill the input field):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

function inputify(elem) {
    var startvalue = elem.value;
    elem.select();
    elem.addEvents({
        'keydown': function(event) {
            if (event.key === 'backspace' && elem.value === startvalue) {
                history.back();
            }
        },
        'click': function() {
            elem.select();
        }
    });
}
 
inputify( $('SomeInputfieldById') );

Great works fine. Remember pre-filled value and only go back in history when the user hasn’t changed it. Done.

Wait… oh, noes! The backspace button is supposed to delete the input. Now, most users will unwillingly trigger the history back function. That’s as broken as it gets… Well, in theory I could focus the input field instead of selecting it, and use something like caretPos, and only go back in history if it’s at the start… But that’s not what I had in mind (well not sure what I was thinking anyway…)

So I consider this technique unusable for the time being for my own sites. The only times I focus some input field onload is for search functions anyway. There, I’d rather annoy a few users and improve the overall usability of the site. Like Harmen said in his post, don’t use onload input focus just because you can

Whenever you list things, IE scripting breaks if you add a comma behind the last element. It’s probably incorrect to add a comma and the examples at docs.mootools.net are all correct. But it surprised me nonetheless as IE lets terribly broken HTML pass and other browsers are more forgiving. Anyway, fixing sloppy code is always a good thing.

This won’t work in the Internet Explorer I tested:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

window.addEvent('domready', function() {
    var elements = $('sidebar').getElements('a');
    elements.each(function(item, index) {
        var elem = $(item);
        elem.addEvents({
            'mouseenter': function() {
                elem.setStyle('background-color', '#ccf');
            },
            'mouseleave': function() {
                var myFx = new Fx.Tween(elem, {
                    duration: 250,
                    link: 'ignore',
                    transition: 'sine:out',
                });
                myFx.start('background-color', '#ccf', '#eef');
            },
        });
    });
});

(Errors on lines 13 and 16)

This will work:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

window.addEvent('domready', function() {
    var elements = $('sidebar').getElements('a');
    elements.each(function(item, index) {
        var elem = $(item);
        elem.addEvents({
            'mouseenter': function() {
                elem.setStyle('background-color', '#ccf');
            },
            'mouseleave': function() {
                var myFx = new Fx.Tween(elem, {
                    duration: 250,
                    link: 'ignore',
                    transition: 'sine:out'
                });
                myFx.start('background-color', '#ccf', '#eef');
            }
        });
    });
});

Some day I may read through the JavaScript specs and find out if this behaviour is to be expected. Another resource I haven’t gone through yet is this excellent post at the mootools blog.

If you’re interested in debugging JavaScript for IE you should read this How to debug JavaScript in IE as well.

When the user clicks into the field you’ll want to remove the clue. The obvious way to do this is to add an onclick JavaScript command:

<form>
    <input onclick="this.value=''" type="text" value="Your email" />
</form>

The user can still access the input field through other means than clicking. He can use the tab key for example. That’s why usually the onfocus event is more useful:

<form>
    <input onfocus="this.value=''" type="text" value="Your email" />
</form>

This seems to work nicely. However there’s still a problem. When a user fills in his email address, reads a little more on your site and clicks the input field again, his address will be removed again! So to make sure this doesn’t happen we add a little check for the content of the field:

<form>
    <input type="text" value="Your email" onfocus="if (this.value == 'Your email') {this.value=''}" />
</form>

And here it is:

Restore default value if nothing is entered

Ok, now this is working. However, when your visitor decides not to input any data, the field stays empty. If you have no label for the input he or she might forget what the field was for. We fix this by restoring the default value when the input field is left:

<form>
    <input type="text" value="Your email" onblur="if(this.value == '') { this.value='Your email'}" onfocus="if (this.value == 'Your email') {this.value=''}" />
</form>

Thanks to Ray for his example linked in the comments.

Select onclick

But sometimes this isn’t the best solution. It could be more desirable to highlight the content of the input field if you’re offering some kind of search. The user may not want to start a new search but to modify the existing one.

By highlighting the input field the user can choose to either empy it by starting to type or to modify it by using the arrow keys.

<form>
    <input onfocus="this.select()" type="text" value="Your previous searcj" />
</form>

Dynamic input color

This is a little advanced. Let’s assume you want the default value to be in a different color and change it onclick. This is one working solution:

<form>
    <input style="color: #f00" type="text" value="Your email" onblur="if(this.value == '') { this.style.color='#f00'; this.value='Your email'}" onfocus="if (this.value == 'Your email') {this.style.color='#0f0'; this.value=''}" />
</form>

Keep in mind that this might create problems when you reload the page. Some browsers will remember the value of the input field, and the color will be different even though the field does not contain the default value. Fixing that is beyond the scope of this post. See onload and domready events.