Published July 7th, 2008
I spend most of my time developing server-side code and testing in Firefox so I don’t usually worry too much about other browsers. But when — as now — I find myself writing JavaScript and CSS, and struggling with all the cross-browser horror that comes with it, I need all the help I can get.
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.
Category: Web Development | Tags: | 1 Comment »
Published July 4th, 2008
Another one of those really obscure ones…
So as previously mentioned, I’m looking at using MochaUI in a CMS project I’m working on. Everything was going swimmingly, except that for some reason it was having rendering problems with (you guessed it) Internet Explorer. At first I thought that it must be a CSS problem, but lengthy experimentation suggested that this was not the case.
With the help of a colleague I eventually narrowed the problem down to MochaUI’s use of Google’s ExplorerCanvas library (excanvas), which provides a wrapper for IE that simulates canvas support. One wrinkle in our use of MochaUI is that the scripts are being loaded dynamically when needed (using MooTools‘ Asset methods). It turns out that excanvas expects to be loaded at page load time, so attaches its initalisation function to the page’s onreadystatechange event — waiting for the page to be ‘complete’ before initialising. Of course, this didn’t apply in our case since the page had already finished loading when the script was included. So it was never initialised.
All that was required to fix the problem was a slight change to the library’s init method (bear in mind, I downloaded the latest version (0002 — dated May 4 2007):
init: function (opt_doc) {
var doc = opt_doc || document;
if (/MSIE/.test(navigator.userAgent) && !window.opera) {
var self = this;
if(doc.readyState == "complete"){
self.init_(doc);
} else{
doc.attachEvent("onreadystatechange", function () {
self.init_(doc);
});
}
}
},
Category: Javascript | Tags: | Be the First to Comment »
Published July 3rd, 2008
As part of the experiments I mentioned yesterday, I’ve been looking at the feasibility of loading CSS on-the-fly. MooTools has a method to achieve this (Asset.css) but I found to my disappointment that its onload event only works in Internet Explorer, so in other browsers you have no way of knowing when the CSS has finished loading (or if it’s failed).
I posted a bug report yesterday and as far as I can tell it’s slated to be looked at for the next release (1.3), but while pondering the problem overnight I came up with an idea and with some help from this blog post I was able to create an interim fix. Because it uses XMLHTTPRequest it can’t load CSS from a third-party domain, but it works for what I need and it’s better than nothing until the official fix is forthcoming.
I’ve put the code into this file (right-click, save as…) which you simply load after MooTools itself (it replaces the existing Asset.css definition with a new one).
Category: Javascript | Tags: | 4 Comments »
Published July 2nd, 2008
I’m just starting preliminary work on a complete (and long overdue) rewrite of our project’s CMS. Right now I’m really just tinkering around, exploring some ideas. As part of this process I wanted to experiment with some dialog boxes, and not wanting to reinvent the wheel I decided to look for a ready-to-use project based on MooTools, our JavaScript library of choice.
My first stop would have been the official MooTools forum, but in their wisdom the project’s leaders have decided to remove them completely. The oft-mooted ‘MooForge’ has never materialised but after exploring a variety of blind alleys I came across MooScripts, an unofficial but quite comprehensive collection of MooTools add-on scripts.
From there I was led to the Mocha UI project, which is a fairly lightweight implementation of dialog boxes for MooTools 1.2. It’s feature list is impressive and it’s quick too (compared to others I tried). Like Mootools it also uses the very permissive MIT licence, which basically says ‘use it how you like, at your own risk’.
Category: Javascript | Tags: | 3 Comments »
Published June 27th, 2008
I’ve been using Firefox 3 for several months now (through various betas and release candidates) and I have to say I’m pretty happy with it. I’ve resisted blogging about it because I think more than enough words have already been written on the subject, but I’ll just say that I’ve been very happy with its improved speed and stability over FF2.
However I do have one caveat to add. I use the portable version (running from a USB key) and found, after some weeks of use, that it was becoming increasingly sluggish. I put up with it for a while but was getting quite frustrated when, one day, I got an error when shutting down the browser. I don’t remember the specifics, but it mentioned a file in my profile directory called urlclassifier3.sqlite.
Out of curiosity I looked at the file and found that it was over well over 70MB in size. This made me even more curious, so I did some searching and found various references to it and its potentially detrimental effect on Firefox’s performance. So I renamed it, restarted Firefox and — presto! — the browser was back to its former, sprightly self.
Some further digging revealed that this is a cache file for data about phishing and malware sites, and can be disabled by unchecking the “Tell me if the site I’m visiting is a suspected attack site” and “Tell me if the site I’m visiting is a suspected forgery” options in Tools > Options > Security. Of course, you do so at your own risk — you could alternatively leave theese options enabled and just delete the file once in a while, when it gets really big and FF starts to slow down.
OK, two caveats: I’m definitely in the ‘I hate the AwesomeBar‘ camp — I’m a
creature of habit and the old-style auto-complete worked just fine for
me. Bah.
Category: Web Development | Tags: | Be the First to Comment »