Window.attachEvent("onload", myFunction) Īnother good approach is to encapsulate feature detection into a set of functions that can then be used throughout the code. ![]() Window.addEventListener("load", myFunction, false) It first checks if the browser supports window.addEventListener and if not, probes for the availability of the legacy feature window.attachEvent: The following script creates two code paths. Now let’s look at a few examples of feature detection. Always target only related features in a single check, effectively minimizing assumptions of a browser’s capabilities.Always test for standards first because browsers often support the newer standard as well as the legacy workaround.There are two very important recommendations to keep in mind when using feature detection: Either way, in this example the page won’t render properly because there’s no code path that connects all the valid code segments even though the page actually contains all the code necessary to properly display in this unknown browser configuration. Browser detection, on the other hand, picks a path based on the browser’s name or chooses the default path because none of the queried browser/version combinations match. Feature detection handles this well and finds out that the browser is capable of displaying Feature A but needs fallback code for Feature B. It’s when faced with an unknown browser configuration that things get interesting. When faced with well-known browser configurations, both methods work, but browser detection has the fixed assumption that both Feature A and Feature B are supported by the browser, whereas feature detection tests for each feature individually. Let’s use the diagrams in Figures 2, 3 and 4 to help visualize how the two approaches work in various situations.įigure 2 Possible Code Paths Through the Test Siteįigure 3 Results with Well-Known Browser Configurations If not, you can follow up by testing for the availability of a workaround or a proprietary legacy implementation of the feature. In most cases this can be done by trying to create a new instance of the feature in question and if that instantiation returns something other than null, the executing browser knows this feature. Before using a feature that you know has different implementations in the various browsers, you run a small test that looks for the availability of a specific object, method, property or behavior. Feature DetectionĪ far better approach to handling differences among Web browsers is to use feature detection. Given all the problems and limitations of browser detection, however, let’s look at an alternative. In the following sample, “ie7.css” is loaded only if Internet Explorer 7 or earlier is detected: url(ie7.css) ĭetailed information on how to use conditional comments can be found in the MSDN Library page, “ About Conditional Comments.” You can use these conditional comments with a CSS to implement certain Internet Explorer-specific CSS rules that you want other browsers to ignore. This syntax extends the standard HTML comments. ![]() Starting with version 5, Internet Explorer has a unique way to detect browsers using conditional comments. The MSDN Library page, “ Detecting Browsers More Effectively,” has more information, and you’ll find a comprehensive article on how to use the navigator object and regular expressions to detect the various browsers and their exact versions at JavaScript Tutorials. Code to run in Internet Explorer 7 or earlier. Var version = GetInternetExplorerVersion() Internet Explorer before version 8 understood the following CSS. Here’s an example of how setting transparency in CSS varied. ![]() Of course, each browser did it in its own way. In the past, as browser vendors raced to become dominant, most implemented the features that were in high demand, even if they weren’t yet standardized. Today, all Web browsers are built with one common goal: Render Web pages optimally according to the latest specifications. In this article I’ll present some tips and best practices that will help you achieve this goal. That means your site has to work not only in today’s browsers, but also in future versions. If you’re building a Web site, you don’t just want it to look terrific today you want it to dazzle for a long time to come. Volume 26 Number 10 HTML5 - Browser and Feature Detection
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |