Archive for the ‘web development’ Category

28 July: Day of Protest against Internet Explorer

Tuesday, April 21st, 2009

(originally posted by me at — some changes have been made since then.)

It’s time for everyone who appreciates good web design and open standards to come together, just for one day, and say, once and for all: Enough already!

Enough already with IE riding roughshod over open, published standards because they don’t happen to suit Microsoft.

Enough already with IE and its downright bats#!t insane default behaviour of executing unknown content.

Enough already with pandering to Microsoft’s buggy, broken virus-trap just because it’s “there by default”.

If one person decided that they were going to block IE, to warn users politely but firmly that they were not welcome to use that malware-magnet that can’t render properly, then that person might lose some traffic.

But if enough people decided, all on the same day, that they were all going to f**k off Internet Explorer users until they downloaded a proper browser — Firefox, for instance, or even Opera or Safari; you know how much recommending a closed-source product sticks in my craw, but anything‘s got to be better than IE — then suddenly the users would have no choice but to download a proper browser, if they wanted to see the Internet. The long-term benefits of that would massively outweigh the short-term inconvenience. Microsoft might even write a proper, standards-compliant browser!

Come on, people. Let’s have a worldwide day of protest against Internet Explorer, stick to it; and by doing so, just maybe improve the Internet for everyone. And that day might just as well be 28 July.

Another register_globals cock-up

Tuesday, January 13th, 2009

When I first started programming in PHP, register_globals was on by default. That was just the way things were; if you had a form field called user, you would get a variable $user appearing magically in your script. And everyone was happy.

Including crackers and script kiddies, who were able to override internal variables with crafted requests and so cause badly-written scripts to behave in ways the writers never thought of. If you didn’t initialise variables properly (And I blame Microsoft for that. Their dialect of BASIC silently initialised numeric variables to zero and strings to “” if you tried to read them before you assigned anything to them. The Sinclair and BBC dialects of BASIC would protest with a “no such variable” error if you tried to read a value from a variable that hadn’t been assigned [and Sinclair BASIC added the LET verb, because a program line had to start with a verb -- that was a constraint of the editor]. The only exception is something like Y = Y + 1, which does work. The reason for that is that the interpreter sees Y = and so reserves some space for a brand new variable Y. Then it tries to evaluate the expression Y + 1 and now there is a variable called Y), or if you relied on a variable coming from $_SESSION not being clobbered by a GET or POST request, well, you got what you deserved.

So in PHP version 4.something, they changed the default behaviour so register_globals was off by default. Now you had to look in $_REQUEST for your form data, or even $_POST, $_GET or $_COOKIE if you cared exactly where it came from. Of course, this broke everyone’s scripts; but if you couldn’t simply re-enable register_globals, then a few lines at the beginning of your script restored the old-style behaviour.

You’d think, therefore, that if you kept register_globals off in your development environment (my desktop running Debian Sid) then yourt scripts ought to run fine on a server with register_globals on (as the deployment environment happened to be). But you’d be wrong. If you take a script which works perfectly with register_globals off and try to run it on a server with register_globals on, and you are using session variables, weirdness ensues.

With register_globals off you can have a variable $foo in your program and a session variable $_SESSION["foo"] and they are absolutely, completely, utterly independent of one another. Once register_globals is turned on, however, it’s a different story. Having assigned $_SESSION["foo"] in one script, any attempt in a subsequent script to assign anything to $foo will also assign $_SESSION["foo"] — even if you haven’t used session_resister() to mark $foo explicitly as a session variable.

I have since formulated a new rule-of-thumb:
Any attempt to combine two “intuitive” behaviours will result in a “counter-intuitive” behaviour.


Friday, February 8th, 2008

<select> lists are very useful in HTML forms, but there’s a problem: an <option> can’t span multiple lines. Which is a pain in the backside, because I had a killer application in mind that would have needed this.