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
||This article possibly contains original research. (January 2013)|
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.
- 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
Creation of W3C and Web standardization
In the early part of the century, practices such as browser sniffing were deemed unusable for cross-browser scripting. 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.
Tools for cross browser testing
There are multiple tools for Cross Browser validation. Most of them are SaaS. Some of them listed below