Primary Menu

Monthly Archives: July 2013

Here’s an interesting problem that came up today during my Gradesolve development: counting the number of words in a particular div. It’s remarkably simple to do so (approximately), efficiently, and correctly. I pass this method the results of a $(“#myelement”).text() call to jQuery:

This returns a result very close to that returned by LibreOffice. It also runs in O(n) (and Θ(n) and Ω(n)). On my hyperthreading-enabled, 3.6GHz Pentium 4 test PC, it took about 0.76ms to count the words in a 400-word document. That means counting the words in a 100,000-word novel would take 190ms or so (not including any memory allocation time) even on a relatively old machine. In other words, it’s quick!

It shouldn’t surprise you that I’m still working on Hawgrade–now called “Gradesolve.” I’ve been making a huge amount of progress with it. Well, I suppose I should say “was making a huge amount of progress.” Today was my dreaded IE day: I’ve been testing everything in Internet Explorer.

Most of my time has been spent with the heart of the Gradesolve experience, the “Magic Editor JavaScript Engine (from Hell),” which I have lovingly named magic_editor.js. A surprising amount of the code has worked flawlessly; most of the changes resulted in something that was better in every browser (A big one was updating some jQuery .css() calls to use .offset()). My updates were coming with relative ease (read: I do not enjoy making my code cater to imaginary standards) until I hit a major snafu with the Twitter Bootstrap modal.

The problem was simple: it didn’t work. Not working, however, is easy to fix. The bigger problem was that the modal worked in the Bootstrap documentation. I was at a loss; I spent hours digging through my code, making messy tweaks, and was on the brink of throwing out the comment editing functionality when I finally decided to look at what was going on with the browser standards inside the iframe in which the magic editor does its magic.

I’ll give those of you who’ve had to go through this the doctype of the page that was inside the iframe (generated by an outside source):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

Yep. WHEN I USED IE VERSION 8 OR OLDER, THE DOCUMENT MODE WAS SET TO IE5 QUIRKS. That’s the rough equivalent of trying to run an iOS app on MS-DOS. It’s not going to work.

Luckily, the fix is relatively easy. I added this to the head of my page (it is not feasible to change the doctype of the served page):

<metahttp-equiv='X-UA-Compatible'content='IE=edge'>

That forces IE to render in whatever the latest and greatest document mode for the browser mode is.