Cross-browser
Cross-browser refers to the ability of a website, web application, HTML construct or client-side script to function in environments that provide its required features and to bow out or degrade gracefully when features are absent or lacking.
Cross-browser vs. multi-browser
With regard to scripts, which is the most common usage, the term cross-browser is often confused with multi-browser (see jQuery). Multi-browser scripts can only be expected to work in environments where they have been demonstrated to work (due to assumptions based on observing a subset of browsers). Most publicly available libraries and frameworks are multi-browser scripts and list the environments (typically popular browsers in use at the time and in their default configurations) where they can be expected to work.
Multi-browser scripts virtually always approach obsolescence as new browsers are introduced, features are deprecated and removed, and the authors assumptions are invalidated; therefore, multi-browser scripts have always required periodic maintenance. As the number of browsers and configurations in use has grown, so has the frequency of such maintenance. Older (or otherwise lesser) browsers and browser versions are periodically dropped as supported environments, regardless of whether or not they are still in use and without concern for what the new scripts will do when exposed to these environments. A typical scenario has them fail (e.g. by throwing an exception during initialization) in ways that were never anticipated by the authors, possibly rendering the document's content inaccessible.
Scripts are categorized as cross-browser or multi-browser based on their logic. A script that uses cross-browser techniques (e.g. appropriate feature detection and testing) is cross-browser forever. Multi-browser scripts (which often rely on browser sniffing) remain multi-browser scripts until they fade away. No amount of testing can distinguish between cross-browser and multi-browser scripts; it is all in the code.
Scripted cross-browser documents and applications must have content that is accessible when scripting is disabled or unavailable, else there would be no usable fallback for the scripts. For some applications (e.g., word processors, games), the fallback content is often little more than a description of what the user would see if scripting were available, as opposed to an empty document or lone error message.
Examples of cross-browser JavaScript
- My Library - The first example of a general-purpose, cross-browser JavaScript library
- Jessie - A repository of cross-browser functions with builder to create custom cross-browser libraries
- Feature Detection: State of the Art Browser Scripting - Article on feature detection and testing in browser scripting
- Matt's DOM Utils - Modular, general-purpose DOM library
History
Background
The history of cross-browser is involved with the history of the "browser wars" in the late 1990s between Netscape Navigator and Microsoft Internet Explorer as well as with that of JavaScript and JScript, the first scripting languages to be implemented in the web browsers. Netscape Navigator was the most widely used web browser at that time and Microsoft had licensed Mosaic to create Internet Explorer 1.0. New versions of Netscape Navigator and Internet Explorer were released at a rapid pace over the following few years. Due to the intense competition in the web browser market, the development of these browsers was fast-paced and new features were added without any coordination between vendors. The introduction of new features often took priority over bug fixes, resulting in unstable browsers, fickle web standards compliance, frequent crashes and many security holes.
Creation of W3C and Web standardization
The World Wide Web Consortium (W3C), founded in 1994 to promote open standards for the World Wide Web, pulled Netscape and Microsoft together with other companies to develop a standard for browser scripting languages called "ECMAScript". The first version of the standard was published in 1997. Subsequent releases of JavaScript and JScript would implement the ECMAScript standard for greater cross-browser compatibility. After the standardization of ECMAScript, W3C began work on the standardization of Document Object Model (DOM), which is a way of representing and interacting with objects in HTML, XHTML and XML documents. DOM Level 0 and DOM Level 1 were introduced in 1996 and 1997. Only limited supports of these were implemented by the browsers, as a result, non-conformant browsers such as Internet Explorer 4.x and Netscape 4.x were still widely used as late as 2000. DOM Standardization became popular since the introduction of DOM Level 2, which was published in 2000. It introduced the "getElementById" function as well as an event model and support for XML namespaces and CSS. DOM Level 3, the current release of the DOM specification, published in April 2004, added support for XPath and keyboard event handling, as well as an interface for serializing documents as XML. By 2005, large parts of W3C DOM were well-supported by common ECMAScript-enabled browsers, including Microsoft Internet Explorer, Opera, Safari and Gecko-based browsers (like Firefox, SeaMonkey and Camino).
This century
In the early part of the century, practices such as browser sniffing were deemed unusable for cross-browser scripting.[1] The term "multi-browser" was coined to describe applications that relied on browser sniffing or made otherwise invalid assumptions about run-time environments, which at the time were almost invariably Web browsers. The term "cross-browser" took on its currently accepted meaning at this time as applications that once worked in Internet Explorer 4 and Netscape Navigator 4 and had since become unusable in modern browsers could not reasonably be described as "cross-browser". Colloquially, such multi-browser applications, as well as frameworks and libraries are still referred to as cross-browser.
References
|