Tag: Solution

The pleasure (and pain) of independent discovery

I was pretty proud of myself when I came up with the solution for the dropdown menus I use in the navigation bar in my current site design. They don’t require all of the cockamamie JavaScript most older solutions did. They surely don’t work in older browsers (I’m guessing), but that really doesn’t matter now. Most significantly to me, though, I had never seen a solution that worked like what I am doing.

I guess it was just a lack of looking. There’s even a term for this approach, Suckerfish Dropdowns, although I’m not doing exactly what they recommend as far as IE support is concerned. However, I haven’t actually noticed it being necessary.

Now that may well be because I’m not even trying to support versions before IE 7, what with all of the transparent PNGs I’ve got everywhere. But still, the solution I’m using works great across all of the browsers I’ve tested: Firefox 2.x, Safari 2.x/3.x, and IE 7. The only complaint I have with it is that the positioning differs slightly between the browsers: the menus appear a few pixels higher in IE than in Firefox or Safari, such that they’re jammed up against the text of the menu header. But if I move them lower, the necessary contact (or really, probably overlap) between the menu header and the menu itself doesn’t happen… and if there’s a gap of even 1 pixel between the bottom of the header and the top of the menu, the menu will disappear if you don’t mouse over it fast enough.

Geez. I read a paragraph like that last one and I just have to ask myself, what am I doing with my life???

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!