| home / programming / javascript / standards |
 
[next] |
|
|
Anyone with more than a passing interest in Web development will be painfully familiar with the process of diligently having to write two sets of code for every single JavaScript application. Every JavaScript tutorial of recent vintage has inevitably focused on grooming prospective programmers into the habit of writing 'in stereo,' as it were, writing to accommodate the two very different approaches to run-time interpretation supported by Netscape and Microsoft.
Now, with the advent of Navigator 6, and Netscape's new "standards only" approach to browser technology, it's entirely possible to write JavaScript code that is parsed without a hitch by both browsers. Better yet, without a single line of code being repeated. (Ed. note: there are some differences between Netscape 6's and IE5+'s DOMs, but there is common ground.)
I've been writing and maintaining Web sites for nigh on six years now. Currently, my sole project is www.iononline.net, a small site dedicated to my band, Ion, and our indy label, Symbiont Records. Iononline.net is low key, designed as a stop off point for fans, with a few downloadable mp3s, and a repository of essays and photos. As such, there's no server side scripting, or dynamic database allocation that needs to take place. There is, however, a lot of incidental JavaScript.
When Netscape released their new browser, I downloaded it, installed it, and then did what any other self-respecting developer would do: took a look at my own site. Immediately I picked up that something was wrong. Nothing worked any more! The image rollovers remained ominously silent. The pop-ups lay chillingly dormant. I'd already spent an awful lot of time working on my code to get it compatible with both breeds of browser, so this wasn't exactly the performance I'd been counting on.
What had befallen me is currently striking a lot of other developers too. People are waking up to realize that the sites they coded for Navigator 4 are static shadows of their former selves under Navigator 6. I've been quite amused in recent days to find some sites have closed up shop entirely; begging pardon while they attend to the situation. The reason for all the hassle is that Navigator 6 isn't just Navigator 4 with a new coat. It's a whole new browser, from the ground up, and by no means is it compatible with any of its previous incarnations. And the reason for this is a pretty good one.
Navigator 6 doesn't play by its own rules. With this new release, Netscape has concentrated on creating a browser that is totally standards compliant; a browser that has no "extra features"; a browser that is prepared to follow out the guides set by the W3C to the letter. All very nice, but at the time I was staring at my broken Web site, and I had no idea why. So the advantages weren't instantly apparent. Obviously I was going to have to make some changes to the site, and soon. But what? Desperately running my cursor over once active images, I jotted down a few of my choices.
Firstly, I could hack the existing code to get a Nav6 compliant version. I wasn't particularly enthused by this option for one simple reason, or rather, a lot of little reasons. It wasn’t just one or two pages that would have to be modified. There are literally dozens of individual pages in the iononline.net site, and the prospect of hunting through each of them to change one or two lines of code wasn't so much daunting, as annoying.
Another option was to code a new site from scratch, and simply make allowances for three browsers. The old and new Navigators, as well as Explorer. Again, I was grinding my teeth. What if I spent the next week diligently chopping away, only to have, say, Microsoft release a new version of Explorer? What then, go back to all the pages, hack in support for a fourth browser? I'd already done this once before, when the very first version of iononline.net had fallen flat on its face after being presented with Navigator 4. It was wearing thin.
The third option, though this one didn't quite hit me until I'd spent some time researching exactly why Netscape 6 was treating my code like so much garbage, was to throw everything that I'd learned about basic Web site construction out the proverbial window. I realized that Netscape 6, of the major browsers, is now the most standards compliant. Second on that list is Internet Explorer 5.5. While both of these beasts have their peculiarities, they both use the W3C’s approach to the Document Object Model (DOM).
The reason that sites are all of a sudden failing when presented with Nav6 lies in the way they were put together in the first place. When laying down JavaScript, the preferred method is, and has been for a long time, to write basically one length of code, but add additional option trees to handle the segments of that code, which are browser dependent. Generally these segments are object referrals, the manner in which you call the browser's attention to something on the page. In other words, they are the aforementioned DOM in action.
In order for JavaScript to figure out which browser it's dealing with, a favorite method has developed in which a programmer will test for certain attributes present in only one of the two browsers. We all thought we were being quite clever when we came up with this, and certainly, it was working out pretty well. At least right up to the point where Netscape pulled the rug and removed all those "test" elements from their browser altogether. At the moment, when Navigator 6 shoulders up to a lot of JavaScript-driven sites, the code is going through with its testing as per usual, but drawing nothing but a big question mark. This leaves the code ambling about, not quite sure what to do. And so it does nothing.
But the interesting thing is not why Netscape decided to undergo such a drastic change (we can only applaud their decision, after all), but rather how. Netscape is currently a lot more like Explorer than it ever was. Enough that it occurred to me that were I to be careful enough, I should be able to use Netscape's new found "standards oriented" philosophy to my advantage. Rather than endlessly rehashing my previous work, I could write a single piece of new code, one that fell inside the W3C standards, and that (theoretically) would work on both browsers without a hitch. The problem of future browser releases would be taken care of. As long as they kept to the standards, then the page would keep on working.
Which isn't to say bells and alarms weren't going off before I'd finished the thought. While on the surface it may have seemed that by conforming my site to nothing but established Web standards I might actually be maximizing my audience, the truth of the matter was that I could quite possibly be reducing the number of viewers dramatically. While the standards are a great thing, they're held back by one or more unescapable facts of life.
The first, and most obvious problem is that even though standards exist, Microsoft and Netscape have, in the past, been notoriously fond of implementing their own "standards," each steadfastly ignoring what the other was up to, seemingly in order to more effectively wind up with two utterly different ways of doing the exact same thing.
It's not entirely their fault though. The other problem facing standardization is the very nature of the Web itself. The Internet is constantly updating itself, and as such, oftentimes when a new technology comes about, like Cascading Style Sheets for instance, it's already being integrated as a "feature" in browsers before the W3C can take a look at it.
Throw in the feudal style warring between Netscape and Microsoft, as each vies to have their take on the newest technology become the norm, and you're starting to come close to a coherent view on why Web programming can drive those of lesser constitution to tears. And that's not even taking into account the other browsers, like Opera, whose existence most Web denizens aren't even aware of.
| home / programming / javascript / standards |
[next] |
This article originally appeared in the Jan. 25, 2001 edition of the WebReference Update Newsletter.
| ||||||||||||||||||||
