milliAmp

In the past I’ve read hundreds of articles about the failings, “features” and related idiosyncrasies of Internet Explorer but until last week I hadn’t heard of this one. When we tested the site in Internet Explorer we found that every page would load correctly and then, right at the last second, change to the standard 404 error page saying that the page could not be found. If the user had turned off the “friendly” error pages in Internet Explorer the site performed fine.

I don’t know about you, but I wasn’t too sure where to start.

After thinking for a while, I checked the headers being sent by the server, they were all fine and dandy. Next I started ripping code haphazardly from the page until the quirk didn’t exhibit itself any more. Turned out that the whole problem was located in the stylesheet. To confirm this, I emptied the stylesheet and reloaded the page, it was fine.

After chopping back and chopping back and then slowly adding back in, I discovered that our designer had used the csshover.htc behaviour file to allow :hover on all elements in Internet Explorer 6. He has used this before successfully many, many times so I knew that something else was amiss.

Anyway, 5 minutes later I discovered that is was being referenced incorrectly from the stylesheet, the URL was given relative to the main page^[1]. The 404 was being generated when the onload event fired for the page when it couldn’t find the .htc to include.

Moral of the story, check your damn code people. A missing forward slash in a stylesheet turned into a 45-minute debugging session.

Another one to chalk up as to why Internet Explorer should die.

^[1] For whatever reason, I think IE was looking for the behaviour in the folder relative to the CSS (which is correct), not finding it and then looking relative to the document it was included from. I say this because the front page didn’t give the 404 whereas every other page did.

I spent a huge part of today trying to determine the cause of a major Internet Explorer performance and rendering regression in a Web Application I'm developing. The reason it was such a bitch to find was because so much code had changed since the last time I had done a proper test in IE6. This was in code which I didn't expect to cause rendering issues, performance issues maybe, but those could have been dealt with.

So, I went through carefully ripping apart the project, disabling stylesheets, removing images, removing individual styles to figure out what was going on. About a hour later I hadn't got very far. I had determined that every¹ browser was fine except IE6.

In frustration, I turned to Google. Trying to find pages describing huge black areas rendering over the page while using Scriptaculous Sortables got my nowhere so I tried searching for causes of huge black rendering artefacts in IE in general... nothing.

I turn back to trying to make a minimal test case. I ended up removing an image that was inside each Sortable item and suddenly the rendering problem went away and the performance jumped up significantly. Anyway, some dilly-dallying around and it turns out it was the javascript I'd written causing problems at all. It was the IE6 CSS Alpha PNG hack which was causing all the problems (which was working fine without performance issues the last time I tested this site in IE6).

It is indeed common knowledge among web developers that IE6 does not support transparency on 24-bit+Alpha PNG images. The alpha channel is rendered [usually] in a baby blue colour instead of being see-through.

To remedy this I was using the fastest hack around the issue that I have found and it involves pasting 5 lines in the CSS file for a site and bingo. I didn't make this hack but here's how it works. It uses the proprietary filter CSS attribute combined with the DirectX ActiveX control to draw the PNG, to target only PNGs and the also proprietary CSS extension 'expression' which uses JScript to compute values. I haven't had a problem with this hack yet, it doesn't handle CSS background images but I haven't needed it to yet.

This combined with the addition of a PNG on each individual Sortable Item caused the poor DirectX Transform to basically crap itself and render parts of the window black. Very black.

Blah.

What a waste of many hours of my day.

Honestly though, this rendering bug caused a few 'wow' moments from people in my office when they saw what IE was displaying on the screen and how it took roughly 20 seconds and 100% CPU to drag one single item between two lists. I'll have a screen-shot of this up in the next few days.

This afternoon, Tom got me to check out a SIMBL plug-in named megazoomer. After upgrading my version of SIMBL and dropping the megazoomer bundle into its place in my Library folder, each Cocoa program I started from then on had fullscreen capability.

With the default key combination that seems borrowed from Windows (⌘ + ⏎ - similar to Alt + Enter which is full-screen/window mode toggle for apps on Windows) it sends the Application full screen.

The big deal for me was that it worked multi-monitor flawlessly even allowing 2 windows to be full screen on different monitors creating an uninterrupted workflow between the two. Now I can set up a text editor on one screen and Safari on the other at work and not have any distractions.

Just spent half an hour trying to figure out a very random bug in a PHP4 application I'm developing at the moment. I'm using an MVC design pattern and in the constructor for the View object I wanted the class to set itself up to capture all output using output buffering. I've used this style in a couple of sites now and once it was all figured out, it worked fine but this time I was doing one subtle thing differently.

This time around I was using the following code:

Which sets the model to an instance variable and provides the output buffering function a callback to the output function of this object. This works fine and dandy, when the page is done, the output function gets called with the parameter being all output that was sent using echo and print statements. The problem is only visible when you want to access instance variables of your object within that function.

Theory One:

The output function was being called on a copy of the original object. Problem was that some of the instance variables were set but the ones set after the constructor weren't. Turns out that the $this variable you get given in the constructor is a special object which you can't pass by reference, only by value.

This was all fixed by calling a bind method after the constructor returned so the code is now similar to:

The bindOutput function is now called straight after the constructor in my bootstrap code.

Anyway, this mildly reiterates to me that I really shouldn't be pushing PHP4 to do things that I should be using Ruby, maybe Python or at very least PHP5 to do.

This was in PHP v4.4.1.

edit: typos for the win
edit2: added syntax highlight plugin

I installed WordPress 2 last week and decided to have a play around with the capabilities and see whether it would be a feasible alternative to my custom CMS which is missing a few features (mainly any blogging capability).

I decided to see if I could port my current site's visual style to a WordPress theme and instead of starting from scratch, I decided play around with K2. It turned out to be surprisingly easy. The fact is, K2's DOM Tree was almost exactly the same as the DOM tree for my site. The differences were mainly around the fact that I'd used ID attributes for my main content divs and K2 used classes, simply fixed, took about 10 minutes to complete and now I have WordPress in my original theme.

I'll probably go back through later today and reinstall the K2 theme and just change the stylesheet instead of what I did which was edit all the files to change the classes/ids around.

I've seen a couple of issues so far, one is that the comment box stretches right out past my container div. The other is that I'm not using any styles from K2 so there aren't any nice things happening with quotes and lists etc that K2 had.

Something I noticed about Themes in WP is that you can almost totally forget about the page content when you're messing around with the ordering of divs and each file is quite independant, finally being brought together in the template files. Nice.

Anyway, I intend to actually blog to my site, I've found a WordPress-integrated wiki which may serve as a replacement for my 'Resources' module, the search is a little better than I had mine.