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.

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.

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).