I began a new job on Monday, and during the day, the subject of website development came up—specifically, what my level of knowledge in that area was. To illustrate with a concrete example, I opened a browser window and pulled up this blog and my personal site. I got a nasty shock. No, the site had not been hacked by a lowlife sending out X-rated spam, nor did the site crash the browser or come up as a disjointed, disorganized mess. I have tendencies toward obsessive-compulsiveness when it comes to a project I have voluntarily undertaken, so what happened was an unpleasant surprise for me despite its minor nature.

I am a Firefox user. I avoid Internet Explorer like the plague, because it is a security threat and is hard to customize to one’s own needs. I love the Firefox add-on database. (Lately I am getting very fed up with some antics of Firefox 3, namely its incessant crashing for no apparent reason and its multi-version, multi-release problem of RSS feeds causing it to freeze at startup. When Google releases a customizable version of its Chrome browser, I may very well switch.) However, Internet Explorer was the only browser available to me on the work computer, and I was immediately faced with the horror of cross-browser incompatibilities. I vowed to do something about this as soon as I returned home.

The text sizes in IE are either subtly different or the browser itself spaces text differently from Firefox, because my “Currently” panel on my main site—an iframe—was generating a scrollbar in IE when it never had in Firefox. The subtle text rendering difference had caused one word to run out of room on IE and start a new line, making the document too big for its parent page, but only slightly so. It was clearly a flaw, not a dubious design choice in which the scrollbar-within-a-tiny-frame was supposed to occur.

The wonderful invention of conditional comments saved the day here. Despite my feelings about IE, I think these are a good thing, one of the better features of that browser, and it would be good for all browsers to start supporting conditional comments for themselves. I simply placed alternate sizes of text within two pairs of conditional comments, the smaller of which would be rendered only on IE and the larger of which would show up in everything else. Hackish or not, I like these things. They’re very useful for the web designer who otherwise would have to compromise her design for all browsers because of IE’s seemingly deliberately obtuse little quirks.

Then I decided that it was a poor idea to have several—perhaps 20—static HTML pages with iframe heights hard-coded into each page, and I wasn’t going to deal with it any longer. I have three panels on that site, all of which sport iframes: the current panel, recent blog posts, and a list of site categories. I suppose I could merge them all into one right-hand column, and I may do that someday if I decide I prefer that design to what I have now. I may also redo the whole site again in PHP and just let the panels be generated. But for now, I like what I have. There was just one problem. If I ever needed to change the height of one panel (because its child page became “longer,” and again, I want to keep scrollbars from appearing in tiny frames), I would have to change that number on every single page that had the panel. I have had to do this before, and I dreaded it each time.

I wrote up a brief JavaScript function to dynamically resize the iframe according to what was contained in it, and (as usual) it worked on Firefox but not IE. Indeed, after scouring the Web for other people’s scripts, I came away with a grand total of zero that worked on both browsers and did all that I needed done. Evidently, this is one of the most infamous browser compatibility issues out there. No wonder languages like PHP, JSP, ASP, etc. have proliferated. If you have semi-frequently-updating data that is duplicated on a large part of your website and don’t want to do these updates the hard manual way anymore, your choices pretty much are a server-side scripting language, iframes, or… JavaScripting it.

As I said, I may decide one day to make the whole site PHP. But now is not that day. It’s a major, major project. And I absolutely will not turn these pages over to a site editor. Even the very best ones can mess up your hard work. When I play with DHTML, I get down and dirty, and my website makes very extensive use of DHTML.

Since I’m not up to re-coding the site in PHP and cross-browser dynamic iframe resizing is still an unsolved problem, my choice was to go with a different use of JavaScript than what I had been attempting. I put all the HTML for the right-hand column of erinthead.com behind println() calls in JavaScript, saved it to an external file, and went through all ~20 pages inserting a reference to that file. The sizes of the iframes were hard-coded rather than dynamic, but now, if I changed something, I’d only have to change it once. Sensible enough.

Well, it used to be that you could count on most browsers to support JavaScript and have it enabled. There was a period of time in the early part of this decade in which all browsers were JS-compatible and NoScript didn’t exist—and for that matter, neither did Firefox. Those days are past. I myself am a NoScript user. It’s almost a necessity if you’re running an older computer, as I am. The Web will kill your machine otherwise, and it’s not JavaScript that’s the problem, but rather, Flash and embedded video. But this otherwise very helpful little Firefox plugin will block it all. It’s a rather popular plugin, too. By making my right sidebar a JavaScript entity, I could easily have been cutting off a large group of users from the content contained therein.

So I had to avail myself of a different kind of “noscript”—this one the <noscript> HTML tag, which can set aside alternate text for non-JavaScript browsers (including those that have been graced with NoScript the plugin). I put up a block of text alerting this user base to the fact that other content was there that could not be seen.

Here’s where things got weird, and I’m still not sure what the problem was. Despite that JavaScript was enabled in Internet Explorer 7, the right panel content and the <noscript> content showed up in that browser. It was very odd. I couldn’t find a bug in my code anywhere; it wasn’t that complicated to begin with! What I ended up doing was availing myself of the most excellent conditional comments again, enclosing the <noscript> in a set of them that triggered only when IE was not the browser being used—in other words, when someone was using a non-IE browser with JavaScript turned off, most likely by NoScript the plugin.

This is hackish because it does not address the Internet Explorer user who has JavaScript disabled. That person does not get content for that part of the web page. I’m not fully satisfied with this “solution,” but the “problem” was so bizarre that I am at a bit of a loss as to what I should even look for. <noscript>-enclosed text has no business showing up when a browser has JavaScript enabled and is displaying JavaScript content. Indeed, this strange behavior didn’t occur with any other browser that I tested, just IE. It occurred to me that there might be an IE-specific issue with <noscript> as an alternative to a non-inline JavaScript (an external file, as I had). Whatever it is, it’s something that is going to bother me until I work out what is causing it.