I 'm OK with pulling it out; I 'm not going to visit any page for my viewing pleasure using IE for sure.

The reasoning behind this though was as follows:
- We can do absolutely nothing to have the problem fixed in IE while at the same time keeping a pixel-specified width for the side columns. If it's one thing I 'm convinced of, it's this.
- Without the "hack", teachers (or even students, when My Moodle starts allowing them to add blocks by themselves?) are mathematically sure to at some point add an overwide image. And they won't all be tech-savvy.
- Result: "Moodle's fault". I 'm talking about people who won't know that there is an alternative to IE (and wouldn't care even if they knew). Why not keep them blissfully unaware of what's going on until IE 7 comes out with an improved rendering engine (dream on...) and the whole universe upgrades?
- Finally, anyone who is savvy enough to actually see what's going on behind the scenes will definitely nod instead of complaining.
That said, if you believe it's doing harm I 'm still OK with pulling it out. I was just having one of my "haven't said my last word yet" fits.

On a related note, while hacking away I noticed that it's
very hard for someone who wants to modify the core to insert something in body onload="". So hard that I didn't do it that way.
In fact, not only you have to have control over all calls to print_header (which you may not have, as in this case) but also a quick inspection left me with the impression that if you
do insert something
and at the same time use the auto-focus feature, the result will be exactly equal to one Javascript error at worst (and your onload will not simply not work at best).
We can do two things to remedy this:
- Pre-emptively have onload call a predefined function anyway, in addition to anything else. This will at least allow people who want to insert their own Javascript an easy entry point (just add your code to the empty by default function).
- Build a better system for adding onload stuff. And an easier way to specify the attributes of <body> incrementally while we 're at it. The $PAGE object would be good for this, and we don't need to refactor the world. Just build the support into page_base and then slowly move things that way while working on Moodle 1.6.
This came out quite long, didn't it?