I’m working on a navigation system that uses CSS image replacement. To hide the text, CSS shifts it out of view by using the text-indent property and a big negative value. However, a side-effect of this is that when you click on a link, the dotted border that appears while you’re holding the mouse button down goes off the side of the page.

To get around this, I just wanted to disable it. After some searching I discovered the outline property — setting this to ‘none’ gets rid of it entirely:

a{
outline: none;
}

Of course, the above will remove it for all links, it’s up to you to decide whether you want to make it more specific.

Now there are various things I should do to prevent this happening — at the very least keep a list of changes as I’m going along, which I do…when I remember to. But on those occasions when I don’t, I usually end up dumping the schemas and comparing them using a diff tool, which works just fine but can be rather laborious.

Today I stumbled (via DZone) upon a piece of freeware called Toad for MySQL. It does a whole bunch of useful things, but the feature that stood out for me was its ’schema compare’ tool. At first it looks like a dolled-up diff tool, but then you notice that in addition to showing you the differences between two databases, it also creates an SQL statement to convert between the two. Very handy.

For those of you who are allergic to MySQL, there are versions of Toad for Oracle, SQL Server and DB2 (although they’re not freeware).

It’s been a few weeks now since I made the decision and I’m starting to become more comfortable with jQuery’s quite different approach. I’ve also begun working on some of the more complicated aspects of the new CMS, including adopting jQuery UI to provide the interface widgets. One requirement of the system is to have a dialog where search results can be dragged and dropped onto a sortable list.

At first I looked at using two sortable lists and the built-in ‘connectWith’ option, which enables you to link two or more sortable lists together. But then I realised that I didn’t really want the search results to be a sortable list. In fact, what I wanted was a static list whose items could be dragged and placed in the sortable list.

I tried a few experiments, and when those failed I decided to try looking at the code itself to see if I could hack together a solution without too much extra effort. While browsing the ui.draggables code, I stumbled across the intriguingly-named ‘connectToSortable’ option. I was surprised to find it because there’s (currently) no mention of it in the documentation, and indeed it’s very hard to find any reference to it at all beyond the code itself (the only useful link I could find was this one, but it rather over-complicates the issue).

It’s very simple to use: as with connectWith, just specify which sortable(s) you want to connect to with the connectToSortable property:

$('#myDraggable › li').draggable({helper:'clone',connectToSortable:'#mySortable'});

Full example code here.

The code for the example works just fine, but I found when using it in my own project, for some reason it was necessary to add a $(‘mySortable’).sortable(‘refresh’) call after defining the two lists, or the first drop operation would always fail.

By the way, when fiddling around with JavaScript experiments I find JSBin very useful — you can load up any of several JS libraries (jQuery, MooTools, dojo, prototype, YUI, script.aculo.us) and create both JavaScript and HTML to test in a ‘live’ environment. Very handy.

I’m creating forms dynamically using JavaScript. This has led to a number of problems with IE6:

Dynamic checkboxes/radio buttons and the ‘checked’ attribute

When creating a field, I wanted to be able to apply a ‘default’ value — for example, a checkbox element might be ticked by default. This was all going smoothly until (guess what?) I tested it on IE6: the checked attribute was set, and returned ‘true’ when tested, but the box did not appear to be checked when it appeared in the form.

The answer, as I discovered thanks to this forum post, was to use the ‘defaultChecked’ attribute instead (I set both, just in case). It seems to work across browsers, which is nice. Oh, and this applies to radio buttons as well as checkboxes.

Creating radio buttons

While we’re on the subject of radio buttons, I also found that IE6 doesn’t like radio buttons created using document.createElement() (i.e. as a DOM object). It’ll render them OK, but they’re unclickable. The answer is to create them by injecting HTML into an element with [element].innerHTML:

var obj = document.createElement( ’span’ );
obj.innerHTML = ‘<input type=”radio” name=”somefield” value=1>1′;

…and so forth. Ugly.

Assigning values to multiple select elements

This was a really fiddly one, and seems to happen under only very particular circumstances. Anyway…

If you create a select element and set the ‘multiple’ attribute, IE6 can sometimes have trouble assigning values to it if you do it immediately after it’s created. Note the word ’sometimes’: I haven’t been able to create a simple enough test case to isolate the exact circumstances that are required. And it’s only a problem if you’re setting more than one value.

Anyway, the (horrible) fix is to delay setting the values using setTimeout(). The delay doesn’t matter (1 millisecond will do), but it does work.

I hope these notes help some other unfortunate soul out there avoid wasting the number of hours and brain cells that I just have!

First (and lasting) impression: damn, it’s fast. It starts fast, it renders pages fast, it stays fast. JavaScript in particular is noticeably smoother where in other browsers it has lagged. The latter is thanks to the new V8 JavaScript engine, the rest is at least partly related to the memory model, where each tab is a completely separate process. Given that it’s using WebKit — the renderer behind Safari — the speed difference between the two is striking.

And to be honest, as far as the ‘wow’ factor goes, that’s about it for me. It’s a browser. The minimalist layout is nice but in fact I’ve been doing myself with Firefox for a couple of years now. Oh, the tabs are at the top…ok. The address bar is ‘clever’…well I don’t particularly like FF3’s ‘Awesomebar’, and I’ve yet to see anything that this does that is likely to make me like it any better. The start page’s layout is very reminiscent of Opera, which isn’t necessarily a bad thing — I might well grow to like it.

But none of the above constitutes a ‘major breakthrough’ or ‘a paradigm shift in the browser space’. It’ll be interesting to see how it develops, though. Maybe the behind-the-scenes, technical advances (esepcially the speed) will feed back into other browser projects. As it stands, it’s just yet another platform to test for incompatibilities.

But…the speed! I can see myself using it as a day-to-day browser for non-development purposes, just because it’s so quick to launch.

Get the modified code here (old 1.1x-compatible version also included).

OK, a lot.

But good as it is it can still be improved, as this list of Firebug extensions proves. There were several on the list that I hadn’t heard of before and have already installed.

So I wrote a very small addition to the Mootools’ own Class code, which allowed this. The new method, Class.bindFunctionToMethod(), allows you either to intercept the method call before or after it’s fired. If fired before you can change the arguments being passed in, while if fired after then you can alter the return value.

Of course you need to be careful how you use it: by ‘piggy-backing’ on method calls like this (especially if you alter the arguments or return value) you’re potentially altering the script’s behaviour in a way that’s not necessarily evident by looking at the classes themselves.

You can download the code here: it’s heavily commented, so it should be fairly obvious how to use it. It works just fine with MooTools version 1.1+ and 1.2.

Opera has made great strides recently with Dragonfly, its own answer to Firebug (the current yardstick by which all other developer tools are measured), and while not quite as good it’s improving all the time. Safari is lagging well behind with its Web Inspector, which promised much when it was relaunched last year but thus far has failed to deliver.

When it comes to Internet Explorer, the situation isn’t as awful as one might expect. Until recently I’d been using a combination of Developer Toolbar and Script Debugger but today I stumbled upon DebugBar, an IE extension which comes a lot closer to Firebug’s functionality, especially when it comes to inspecting CSS rules and so on. Its handling of JavaScript errors doesn’t improve much on IE’s own abilities — it still won’t tell you which file an error has occurred in, for example — and it seems to have trouble inspecting some script-created elements. Still, worth a look.

UPDATE: while we’re on the subject of developing in IE, I should mention CachePal, a shortcut button that clears IE’s cache. Handy when you’re developing (say) JavaScript, because IE has a tendency to hang onto old JavaScript files even after a SHIFT+Reload.