Tag: Explorer

Still wish you were using Internet Explorer 6?

If you’ve never visited this site using Internet Explorer 6, you probably are unaware that up until now doing so would load a big ugly alert box explaining how foolish you were being to do so — being that I am an arrogant Mac and Firefox user, not to mention that IE6 is dangerously insecure (besides not supporting alpha channel transparency in PNG images, which are the building blocks of this site’s design).

Today I had the chance for the first time to see just how horrible the new design looks in IE6, and as much as I don’t want to support that browser, I also couldn’t handle thrusting visitors into the hideous mess of this site in IE6 without at least giving them a taste of what it’s supposed to look like first. To that end, I’ve created a more friendly “welcome” page for IE6 users, giving them one last chance to upgrade before proceeding, and in the process showing them a hint of the site’s actual design as it’s intended to appear.

But of course, since you’re not using IE6 (are you?), you have no idea what that page looks like. So, I thought I’d show it off a bit. Here it is. Enjoy. Or not. Actually, it’s not really intended to be enjoyed, so don’t. (I’m really only posting this link so I can test the HTTP_REFERER link functionality I embedded in it. [And yes, I know the correct spelling is “referrer.” Tell that to whoever created the names of the HTTP host headers. I mean whomever. So there.])

All hail PNG!

According to the official spec, it’s actually pronounced “ping,” which I dislike: “ping” already means something very specific (and very different) in the Internet world. But I’ll go along and stop calling it “pee-en-gee”. Apparently I have to start calling GIF images “jiffs” as well, since that’s what the creator of the format calls it. (Maybe as a form of rebellion I’ll start saying “LIE-nux” — or not.)

Anyway… savvy reader(s) will know I’ve actually been using PNG images featuring the all-important alpha channel transparency for nearly a year on my site; it’s what allowed me to swap in the various 34-themed photos in the old design as an underlay below the logo and navigation bar without having to create separate versions of the logo and navigation button graphics for each separate photo. Alpha channels allow you to build transparency information right into an image, so images can be overlaid directly on each other with complex layering effects, regardless of the color of the background. (This is all exceptionally arcane for anyone who doesn’t do web design, or more generally, graphic design; but to us in the field it’s potentially huge.)

Now, PNG has been around for several years, but almost no sites I’ve seen are really taking advantage of alpha channels yet, and with good — or at least, understandable, if lamentable — reason: Internet Explorer did not properly support PNG alpha channels until version 7, which just came out earlier this year. As a result, even though Firefox and Safari have both been able to display these images properly since their inception, no one could really use the format unless they were willing to have upwards of 90% of their visitors look at garbage.

I for one am willing to have my visitors look at garbage: if they’re using Internet Explorer 6, that’s what they’re dealing with anyway! Hence, for those of you who may still be using IE6, I present my annoying JavaScript alert whenever you enter the site. (The rest of you have no idea what I’m talking about, and be glad for it.)

But now, according to log stats on the sites I’ve developed at work (where I actually have stats to look at), the majority of Internet Explorer users have upgraded to version 7. Combine that with the fact that increased usage of Firefox and Safari (corollary: increased use of Macs) has pushed overall IE traffic down to around 80%, and I felt like the time was ripe to dive into a full-fledged transparency fest with this new web design.

Maybe I’ve just been slipped more of Steve Jobs’ special Kool-Aid, but since I’ve gotten to the point where I almost like Leopard’s translucent menu bar, it only seems fitting that I should honor (or, if you prefer, imitate) this new direction in computer interface design, legibility be damned! (OK, I know Microsoft’s on the transparency train too, and it’s hard to say who’s really pulling the mixed-metaphor cart here; Vista came first but Leopard is still ahead of it, and the whole concept behind Vista’s interface seemed to be another attempt at playing catch-up to Apple. But I digress, as usual.)

I actually no longer have access to any Windows computers that haven’t been upgraded to IE7, so I have no way of knowing what the new pages look like in IE6. I expect they’re pretty terrible. Guess what: blame Microsoft!

All hail PNG!!!

Note: I’ve just discovered that there’s a weird problem with an unexpected background image showing up across the top of the page in Safari 2.x, which is the browser most Mac users are running unless they’ve wisely switched to Firefox or zealously upgraded to Leopard. (In other words, it looks great on my MacBook, but I noticed the problem on SLP’s iBook!) I’m hoping to have it fixed soon… once I figure out where the hell it’s coming from!!!

Web 2.0 — opening up a whole new world of Internet Explorer quirks!

Just when I needed it least, Internet Explorer has thrown me another curveball.

I’m hard at work trying to seem like less of a 20th Century web dinosaur by acquiring new skills with these techniques that are loosely lumped together into what some call “Web 2.0.” Key among these is an approach called AJAX (Asynchronous JavaScript and XML). Fun stuff. I’ve been working for the past several days on an interactive registration form for a site at work, using AJAX. Of course, as usual, I’m plugging away in Safari and Firefox, but eventually I decided to check out how things are looking in Internet Explorer.

[When I figure out an emoticon that represents my head exploding, I’ll insert it here.]

IE is consistently barfing on what it claims is a syntax error that I eventually tracked down to the evalScripts function in prototype.js. Well, at least it’s not my own code that’s making it crap out this time. Or is it? With IE you never can tell. Maybe evalScripts is buggy (even though I can find no evidence to that effect) or maybe it’s just the code in my script that’s being thrown at it. Whatever the case, once again all forward progress has come to a grinding halt while I scour the Internet fruitlessly for a solution.

Although this turned out not to be a solution to my problem, I just have to refer you to this developer’s blog entry on a typical IE workaround. Yes, I tried this, even though I was almost positive his problem was completely unrelated to my own (which was the case). Nevertheless, when a problem does arise in IE, the most likely eventual result of one or more days’ worth of sleuthing is the resigned acceptance of such hokey code bloat, rather than anything even remotely satisfying (or even logical).

There you have it. As for my own problem using prototype.js with IE, I did find a solution. Yes, it was my code, and it was something I had seen previously that was pretty much staring me in the face, if I had just bothered to heed Thomas Fuchs’s sage advice.

It all comes down to standard practice for wrapping <script> tags in HTML. I still have the habit of doing it this way:

<!–
//–>

The funny thing about that is that I know it’s completely pointless these days. It’s done so that browsers that don’t support JavaScript don’t inadvertently display the JavaScript code in the web page. But every browser has supported JavaScript since about 1997, so it’s pretty ridiculous to keep doing that. Especially given that, the way the sites I’m working on are so utterly dependent upon JavaScript, you’d never even get to the page in question without it.

However, with XMLHttpRequest (which is at the heart of AJAX), and just the increasing complexity of JavaScript in general, it’s become necessary to wrap script code in a new tag to ensure that browsers handle the code properly. To wit:

// <![CDATA[
// ]]>

Just as Thomas Fuchs said. And just as has been lingering in the back of my mind for the past several weeks, since I first discovered his wonderful tool based on prototype.js, Scriptaculous. I’ve learned my lesson.

Quickly now…

Just a quick one, as I don’t have a lot of time to post… but of course, as usual, I had to make time for a detour into the madness of Internet Explorer when I discovered that my CSS line-height positioning was breaking when there was an inline image in the text. Why? Who knows? But the solution involved sticking vspace=”7″ into each offending image tag. Yet another case of hacking a one-off solution into the code to work around an Internet Explorer quirk. Almost as frustrating as IE’s violations of standards is the fact that there’s almost never a one-size-fits-all workaround!

Forget what I said before; we have a winner!

It’s a given that anything I post here is going to be brain-deflatingly stupid. But this one goes beyond even what I would have expected of Microsoft. Fortunately, thanks to a highly effective Google search, I was able to solve the problem in minutes.

The problem was this: For a site I’m working on, we are manipulating the 404 error feature to allow users to set up customized URLs. If the URL entered doesn’t match a real page, it gets fed into this 404 error script, which looks up the path in a database and redirects the user to their customized page. A bit of a hack, but it’s pretty slick.

As usual, I am developing the site using Firefox as my test browser. But… UH-OH! Surprise! When giving a demo of this feature today using Internet Explorer, we discovered it didn’t work! Internet Explorer was not returning the server’s 404 error page, instead using its own internal version (which we’ve all seen and most generally ignore).

Drat! What to do? Well, as it turns out (thanks to the aforementioned Google search), the problem is quite simple. To quote the unbelievable but, as I verified, 100% accurate description I found on this page:

Internet Explorer has a lightly-documented “feature” that stops it from serving any custom 404 error page that is less than 512 bytes long. Your visitors will instead be sent to IE’s own 404 page, which is generic and suggests they use an MSN search to “look for information on the Internet.” That’s one way to lose visitors! Make sure your custom 404 error page is over this limit — about 10 full lines of text and HTML should be enough.

Yep, that’s it. I did my best Bart Simpson-at-the-blackboard impersonation, filling my 404.html file with a large comment block wherein I repeated (about 130 times, for good measure) the phrase “This block exists solely to force Internet Explorer to load this page.”

Sure enough, it worked. D’oh!

Thinking a bit more about this, I at least think I understand why Microsoft chose to do this. “If the server’s default 404 error page is so short,” I imagine them musing, “then it probably doesn’t offer users much helpful information. And since our wonderful web browser is much more important to our users than the web pages themselves, let’s just butt in and do things our way. (Is there really any other way anyway?)”