Quirksmode

Today I fixed several browser-specific bugs affecting my puzzles. I want to discuss them, briefly, as they took a while to track down, and so seem to merit comment.

Events (MochiKit / IE6)

As I mentioned yesterday, IE6 wasn’t responding to the arrow keys. This turned out to be because I was not capturing keyboard input properly. As background, I should mention that I’m using MochiKit for event processing, and implementing the arrow keys by trapping all keyboard events, then scanning the event stream for arrow key input. This was my first pass at implementing the trap:

connect(window, 'onkeydown', this, this.HandleKeyboard);

This worked in FF and Safari, but not IE6. I was able to make the trap work everywhere by recoding it as:

connect(document, 'onkeydown', this, this.HandleKeyboard);

In summary, events bypass the window object in IE6, so you must associate your event handlers with the document object if you want to trap everything.

Events (Safari)

Safari (v2.0.4) fires 2 keydown events for every 1 press of the arrow keys. This is apparently a known problem – it just wasn’t known to me. You can work around this problem with the MochiKit event object’s stop() method:

App.prototype.HandleKeyboard = function(ev) {
	var code, name, dr=0, dc=0, s=this.board.size;
	switch (ev.key().string)
	{
		case 'KEY_ARROW_UP':
			dr = -1;
			ev.stop();
			break;
		// ... snip ...

Events (OS X)

Neither Safari nor Firefox on OSX 10.4.9 seem to generate repeating keydown events when a key is held down. I couldn’t find a simple workaround, so I guess my Mac users will just have sore fingers. Sorry, guys.

IE6 Tables and DHTML

IE6 doesn’t seem to like it when you update the styling of table cells. On the other hand, it seems safe to change the classes (i.e. the className DOM member) of those cells. A switch from the first technique to the second fixed the graphical glitches related to cell highlighting that I mentioned yesterday.

Whitepapers

To turn to marketing for a minute: Whitepapers are slightly sneaky marketing tools, which present themselves as dispassionate analyses of a problem, but which (conveniently) end up recommending their author’s preferred solutions. (“Author”, in this case, is someone selling something, and “preferred solution” is his product.) This isn’t necessarily unethical; if the paper’s reasoning is sound, it’s just good advice that the author is highly motivated to give.

Since my experience with Adwords has led me to believe that there’s something about my puzzle page in particular that Google doesn’t like (since, e.g., Adwords assigns a higher quality score to my solver than my puzzles) I’ve decided to try the whitepaper approach. I’ve created a simple site which compares all the KenKen-style puzzle sites I’ve found, and which features mine prominently. I will shift my advertising efforts to this site, which, hopefully, Adwords will like more than my other pages. I consider the site a legitimate resource; it’s content is fair, and my site really does stack up very well against anything else out there.

Future Work

My immediate plans are to:

• Release and advertise the whitepaper
• Refine support for puzzle printing
• Begin researching widgets

Yesterday’s Stats

I’m beginning to find these stats a little discouraging. Let’s see if the whitepaper helps matters at all.

Follow Along

You can subscribe to my RSS feed, if you’d like to follow along with this month’s project, in which I attempt to create and popularize a puzzle site.