 | Level: Introductory Peter Seebach (crankyuser@seebs.plethora.net), Writer, Freelance
30 May 2006 To entice developers to create sites that render best in their specific browsers, vendors have fueled a compatibility war using scripting languages as their weapons of choice while users get caught in the middle with slow-loading Web pages and potential security holes. As the market drives such (unhealthy) competition, it's clear that it's time for better standardization. See what you can do to stay on neutral territory until that day comes. ECMAscript (better known to most people as JavaScript) has a particularly interesting history in that it started out as an anti-standard. That is, ECMAScript is essentially the same language as both JavaScript and JScript languages, the competing languages used respectively by Netscape and Microsoft.
The technology was first called Mocha, then LiveScript, and was first officially introduced as JavaScript in 1996. However, it has no technical relationship to the Java™ language; the name's significance can be attributed purely to marketing. Sure, the press release implies some sort of connection between server-side Java and client-side JavaScript (see Resources); in fact, there is no connection at all.
Netscape's market dominance forced Internet Explorer to support a compatible language -- mostly compatible, anyway. Internet Explorer came out with JScript, which was almost compatible with JavaScript.
Standards wars
|
What is the Open Ajax Alliance?
In the hours before the JavaOne trade show in May, 2006, representatives from 29 companies meet in conference rooms at Adobe Systems, trying to determine the future of Ajax in general, and their group, known as OpenAjax, in particular.
The group made several decisions, including the most visible one, to give itself a name: Open Ajax Alliance. It also decided not to make itself a formal standards body, or open-source hosting organization, such as the Eclipse Foundation, and leave its structure informal for now. The group agreed to meet once a week or so in a teleconference.
The Open Ajax Alliance will focus on three areas: decrease the risk of AJAX adoption by providing interoperability; ensure that AJAX solutions adhere to open standards and use open-source technology; and preserve the open nature of the Web.
The group's first task is to find ways to establish and maintain interoperability among Ajax tools.
The OpenAjax Alliance consists of 31 technology vendors including IBM, Adobe, Eclipse Foundation, Google, Laszlo Systems, Oracle, Red Hat, and Zend.
|
|
What happened next is simple: every new version of Netscape and Internet
Explorer added exciting features that were incompatible with the other
browser. The apparent goal was to get Web designers to commit to a page
viewable only in one browser, by making flashy new features available only in
a proprietary language. You might see some similarity to this and the conflict
between Java and J++, which was happening around the same time. The clash
between JavaScript and JScript was rooted in the perceived economic benefits
to Netscape and Microsoft, but was not so good for anyone else. In fact, those two companies suffered from the cost of trying to maintain compatibility by engineering incompatible code.
Formal standardization efforts began in 1996, when Netscape submitted the
JavaScript specification to ECMA International; a standard was adopted in June 1997. The current standard (ECMAScript Edition 3, 1999) is ECMA-262, which corresponds to ISO/IEC 16262.
This, however, didn't stop the war. Both JavaScript and JScript are compatible with ECMAScript, but they continue to have substantial differences and extensions. Their respective companies use the differences to entice developers into saying a given page only works with a given browser, or stating that a given browser will give the "best" page display.
Some developers simply ignored the question of which browsers might work
with their pages, but some carefully checked for compatible versions before
trying anything. They did so by checking the user-agent string (a
string that the browser provides the server) for version information.
Unfortunately, many Web developers settled on "Mozilla/X.0" in the user-agent string as the standard for detecting Netscape versions. If the user agent wasn't Mozilla, various features were omitted or disabled; as a result, these pages would render incorrectly, if at all, in every other browser. So, Internet Explorer began to use user-agent strings claiming to be a version of Mozilla!
Other players
Into this already-tangled situation came the developers of new browsers, such as Opera, iCab, and Konqueror, who were primarily interested in rendering all Web pages as well as possible. Because many Web pages made key features conditional on a user-agent string beginning with "Mozilla", more vendors imitated Internet Explorer's technique. Many modern browsers support sending misleading user-agent strings, and even for selecting which browser to pretend to be. This is a market-driven feature; a new browser can probably render millions upon millions of pages if, and only if, it gives such a user-agent string. Many sites try to check for, and block, specific browsers that might or might not have problems rendering them.
While browsers are the most likely platform to specifically refer to the ECMAScript standard, or to identify a particular version, they are not the only technology to support the standard. Some versions of Macromedia's Flash use a variant called ActionScript. Adobe's Photoshop
uses JavaScript too. Of particular interest is Konfabulator, a JavaScript runtime for Windows and Mac OS X, which provides a way to do widgets, such as stock tickers, small video games, and so on.
Effects of a standards conflict
The most obvious effect of this standards conflict comes from the delay caused by the huge and elaborate scripts that Web pages must use to identify the browser before performing a task. Some programs have pages and pages of scripting to identify browsers, with workarounds for multiple versions.
These scripts are not solely a result of a standards conflict; after all, Web pages might need some of this merely for determining which standard version a given platform complies with. Still, the early implementations of JavaScript/JScript were dramatically incompatible in this respect, often offering no hints about versions, or doing so in wildly incompatible ways. It was not enough to ask for a version; Netscape and Internet Explorer might not return it in the same way! Of course, more elaborate workarounds might have resulted from developer confusion rather than from lack of support for version-checking. For instance, one such program used in an online store software fulfillment used a giant script to figure out whether you were on a Mac or a Windows machine (the only options it supported) to decide whether to give you a zip file or a StuffIt archive, even though the downloaded software was platform-specific. The whole script was a waste, as was the half hour it took me to build a static page with the correct download links when the script failed on my browser.
A disturbingly large amount of code assumes that the presence of a particular extension is proof positive of a given implementation. For instance, some developers might check if (document.layers) and then assume that, if the check succeeds, the host browser is specifically Netscape 4, and use all sorts of Netscape extensions, or even just standard features that are not widely implemented outside of that Netscape version. Don't do this! You'll be asking for trouble when a browser implements one feature but not another. Instead, use the standard. (The Mozilla people offer an excellent example of well-written "sniffer" code to identify JavaScript implementations; see Resources).
Although the traffic caused by this workaround is a tiny fraction of the overall Web traffic, it is interesting to estimate how many billions of times the string "Mozilla" is sent as part of a user-agent identifier in order to fake out naive scripts. If JavaScript had simply started with an easy way to check versions or perform feature tests, and developers had made better use of the available support, this would all be unnecessary.
Other variations
One major change in the last few years was the development of browsers with specific, intentional, and well-documented deficiencies in their JavaScript implementations. I refer, of course, to pop-up blockers. The original JavaScript standard allowed scripts to perform several actions that were potentially intrusive. Intrusive is really not a strong enough word; some scripts were designed to do things that were more like the actions of a virus than the actions of a Web page (for instance, windows that used the onUnload method to open new windows when closed!)
While some of these malicious programs were merely inconvenient, or embarassing (some play loud sound files in the hopes of attracting coworkers to a hapless victim's desk), some were potentially very dangerous. A security nightmare involves the option of creating new windows in which the URL is hidden -- which is to say, windows in which an attacker could potentially load some alternative page without the user knowing. Various browsers have developed defenses against unwanted behaviors from scripts.
This conflict continues to escalate, as sites develop new ways to display messages with JavaScript code, and browser vendors seek new ways to suppress unwanted messages. Some sites have made critical site functionality dependant on the exact same script techniques used to display ads, so users can't access the site's primary function without exposing themselves to unwanted ads.
Future directions
Continuing standardization in ECMAScript is still happening. The forthcoming JavaScript 2.0 language standard and the ECMAScript Edition 4 standard are supposed to be essentially the same language, although JavaScript will have some extensions. The JavaScript 2.0 page explains that "JavaScript 2.0 will also include a few features for which more feedback and experience is appropriate before standardizing them."
If users are lucky, developers will experiment with and explore these features, but not use them for the core functionality of Web pages. In the past, I have argued in favor of reasonable early standards adoption, but it is important when adopting a new spec to remember that not everyone has support for it yet. Still, it's a good thing for everyone to test things openly and above-board before putting them into the field.
One future direction that merits special discussion is Ajax, which is short for "Asynchronous JavaScript + XML". The intent is that scripts on a page can do some amount of dynamic work, obtaining new data and revising their display, without reloading the whole page. In theory, this could dramatically reduce the bandwidth requirements of some sites, as the scripts load large pieces of a page once, and then refresh and upload smaller parts. This is not really a new standard per se, but it is an application of ECMAScript languages that pushes the need for better standardization in browsers, and some degree of feature expansion. The more complicated a script is, and the more features it relies on, the more important it is to developers that the underlying platform is stable and flexible.
Hopefully future revisions of the standard address the current version's security issues, although this would necessarily entail a loss of some current functionality.
Making effective and safe use of scripting
What does this mean to you as a developer? Well, first, it means you need to try to minimize gratuitous dependencies. Some pages use onclick script activation to load new pages, replacing all the URLs on their page with "#". This is just annoying. Don't do it.
When you develop a script, make sure you understand what will happen if scripting is disabled. One major vendor's Web site, for several years, simply came up as a blank white page if scripting was disabled -- even though the only thing it needed scripting for was to determine whether your browser supported Flash animations. (A more recent version displays a message saying that you need JavaScript for various functionality, such as site navigation. This is not much better.) If you must have scripting, try to keep it under control; after all, many browsers for people with disabilities have limited scripting functionality.
Once you're onto the script, think about on which browsers you need to run. If you can rule out the oldest browsers (or provide script-free functionality for them), you can simplify your code dramatically. Some simpler scripts might be portable everywhere; others might require several features, or multiple implementations of a given piece of code, one for each of several competing so-called standards. You can identify most common JavaScript versions in code in a fairly portable manner (see Resources for more information). Try to isolate your platform-specific code. Don't just assume Internet Explorer; too many people use unusual browsers (cell phones or PDAs) or prefer Firefox.
Remember that pop-up blockers are out there, and users hate having to change settings; indeed, many users cannot change settings, either due to user skill level or to system administrator controls. Limit your scripting to things that will work even on a browser that's been at least partially locked down.
The more you can stay at the center of standards, rather than out on the fringes of extensions, the less work you'll have to do on compatibility, and the less trouble you'll have with new browser versions. In nearly all cases, you can confidently expect that you will have to maintain pages through at least one significant browser release. Plan for it.
Resources Learn
Get products and technologies
Discuss
About the author | 
| | Peter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though. |
Rate this page
| |
