
The double-margin bug in IE6 is one of those inexplicable behaviours of the aged browser that nobody quite understands: the developers claimed to be following the W3C’s CSS standards with IE6’s rendering, but sometimes this can almost be forgiven: the rules and guidelines are written down in such a verbose and brain-shattering verse that it’s very easy to see where people would perceive different outcomes when reading the same thing.
Not even a year ago, I spent a couple of days wrestling with Mark Davidson’s sIFR in an attempt to find a cross-browser compatible method of embedding custom fonts into a website I was developing, which the designer absolutely insisted could not use a normal web-safe font. Of course I very quickly gave up and reverted back to a PHP dynamic text replacement module - for all the great things that sIFR has done for the web developing community (and especially in reducing arguments between designers and front-end developers), it’s an absolute pig to get to work reliably across browsers and can really reduce the usability and loading of your site. Not good.

One of the biggest problems with larger application developments is the maintenance. If you’ve ever worked for a company, or somebody (or have been that somebody yourself), who decides on a whim that the dark blue colour used extensively across your website should really be a light shade of green (yuck!), then you can appreciate how time consuming and troublesome this sort of “simple” change can be.
In the never-ending quest to reduce the amount of bandwidth your website uses (both to improve visitor load times and to keep your own overheads as low as possible), one of the simplest and easiest areas for improvement is often overlooked: compress your CSS and JavaScript.
Even just taking out all the erroneous white space can make a huge difference in the final size of the file. Of course, it annoys the hell out of people trying to digg through your code, but I sort of see that as an advantage too..! Of course, compressing your CSS and then having to revert back to an uncompressed version every time you want to make a change and re-compressing it again becomes a bit of a bore very quickly, so why not an automated method that will do it for you? With PHP and htaccess, it’s very, very easy.
It’s an incredibly simple rule of thumb, and one that I’ve reminded myself of at least twice before but somehow I seem to always forget and then spent twenty minute pulling my hair out with FireBug open trying to work out why the bl**dy thing isn’t behaving as I expected it to (of course it’s fair to say everyone has days like that!)

Nice Pictures are a relatively young company made up of a group of experienced and dedicated producers focused on delivering quality feature films for cinema and DVD.
They commissioned me to develop and deploy their website in order to create a central repository to keep investors informed of their progress, to advertise the seven films they currently hold on their slate, and to attract more interest.

At the time this was developed I was working for a mid-sized marketing agency who’s intranet was old, ugly, buggy, and unreliable. The intention of this project had been to reduce the number of headaches and problems the current intranet caused by replacing it with an all-singing, all-dancing replacement, offering all the functionality that had either failed or never been included in their original intranet.






