November News

Okay I haven't died yet, it's just been pretty boring on the news front for the blog.

Let's see, I've spent the last two weeks practically home alone: two flatmates in the South Island, one in Australia for a week, means one Jeremy at home cooking delicious food for himself, and playing absurd amounts of DotA. Not that either of these things are bad. I brought DotA to work on my iPod in the hope I could attract some interest and get my workmates to play as well.

I had a flatwarming for three of my workmates last night too. They live about 20 minutes up the road from me, so maybe I'll see them on the bus or walking home or something. But it was a pretty cool party, got to hang out with people and socialise and stuff. Woo~. Got caught by the rain as I went home, but luckily the bus was on time and I managed to minimise the wetness.

I've been doing a lot of web development lately. I fixed some spam bot problem with my Shoutbox a few minutes ago, and I thought I'd blog about something that's been infuriating me for the past few weeks.

The majority of the world have this program installed on their machines and actively use this malicious application. I do not know the exact numbers, but whatever the statistics are, it is far too much for people to being using such filth every day.

I am, of course, talking about Internet Explorer.

Who the hell at Microsoft decided to make a substandard browser with so many security flaws and a blatant disregard for web coding standards just to piss developers off? Morons. Absolute bloody morons.

In this site I've been working on (You know the one, Stephen :O), I have this search box that appears onmouseover, and it disappears when you click outside the box, but should remain visible when clicking inside the box. The easiest way to implement this was to cancel the bubbling effect that events have, that is, clicking inside a table will trigger its onclick, its parents onclick and continue up the chain until there are no more onclick handlers.

So, if the table onclick is specified and the event.returnValue parameter is set to false, I can use this value to prevent subsequent calls to the onclick handler. Thus, when it gets to the body onclick, inside the handler, I just return prematurely if event.returnValue is false.

Yup, that's all great. Works wonderfully on Firefox. This behaviour also works on Internet Explorer too...oh, wait. Hold on a second. By specifying that the event's returnValue is now false in Internet Explorer, all onclick handlers no longer work. That means onclicks for anchor tags and submit buttons. What kind of stupid system is that?

I resorted to using the following code:


<script type="text/javascript">
var eventHandled = new Array();
function myFunction(event) {
    if (eventHandled[event.type])
        return;

    eventHandled[event.type] = true;
}
</script>

<body onclick="myFunction(event); eventStates = new Array();">

<table onclick="myFunction(event);">
    <tr>
        <td>No Click</td>
        <td><div onclick="myFunction(event);">Click</div></td>
    </tr>
</table>


Clicking on the innermost <div> with "Click" calls myFunction. myFunction sets eventHandled["onclick"] to be true, and prevents bubbling up by halting execution of the onclick in the <table> and <body> tags. Finally at the <body> tag, the states are reset to ensure that the next onclick can be processed. Phew!

Stupid Internet Explorer.

(PS: I should look at getting some syntax highlighting...)

Comments

Steve (10:04am Sunday November 23 2008)

I have no idea what you're talking about. >.> <.< Furthermore, it is my opinion that Carthage must be destroyed.

br (02:49am Monday November 24 2008)

I'm using IE to browse your site right now XD