Test Driven JavaScript Development- P12

Test Driven JavaScript Development- P12:This book is about programming JavaScript for the real world, using the techniquesand workflow suggested by Test-Driven Development. It is about gaining confidencein your code through test coverage, and gaining the ability to fearlessly refactor andorganically evolve your code base. It is about writing modular and testable code. Itis about writing JavaScript that works in a wide variety of environments and thatdoesn’t get in your user’s way.
Nội dung trích xuất từ tài liệu:
Test Driven JavaScript Development- P12 10.6 Using Feature Detection 213 return dom.customEvents[event](element, listener); } return _addEventHandler(element, event, listener); } dom.addEventHandler = addEventHandler; }()); The mouseenter implementation keeps track of whether the mouse is cur- rently hovering the target element, and fires anytime a mouseover is fired and the mouse wasn’t previously hovering it. The method uses dom.contains(parent, child), which returns true if an element contains another. The try-catch pro- tects against a bug in Firefox, which will sometimes provide an XUL element as relatedTarget. This can happen when mousing over for instance a scroll bar, and unfortunately XUL elements throw exceptions on any property access. Addi- tionally, the relatedTarget may be a text node, fetching its parentNode gets us back on track. To practice feature detection, I encourage you to take this method for a spin, find more browser quirks, and smooth them over by detecting erroneous behavior and correcting it. 10.6 Using Feature Detection Feature detection is a powerful tool in cross-browser scripting. It can allow many features to be implemented for a very wide array of browsers; old, current, and future ones. That does not necessarily mean that employing feature detection implies that you should provide fallback solutions for any feature that may not be supported. Sometimes, dropping support for old browsers can be a statement in itself, but we should be able to do so without sniffing out the browsers we want to send down the degradation path. 10.6.1 Moving Forward If supporting a troublesome old browser, oh say Internet Explorer 6, costs more than the benefits can defend, businesses sometimes actively decide to drop sup- port. Doing so does not mean we should pretend “unsupported” browsers don’t exist. Using unobtrusive JavaScript and feature detection can ensure that when a browser is no longer actively developed for, it will receive the usable but possiblyPlease purchase PDF Split-Merge on www.verypdf.com to remove this watermark. From the Library of WoweBook.Com 214 Feature Detection basic fallback solution. In such cases, feature detection can be used to discriminate incapable browsers. Going back to the strftime example, if we don’t want to support enhanced features in browsers that cannot handle a function argument to String.prototype.replace, we simply abort the definition of the method in browsers in which this feature test fails. Interfaces that use this method may choose to do the same, i.e., if the strftime method is not available, higher level enhance- ments that depend on it can choose to abort as well. As long as feature detection is built into every layer of the application, avoiding some or all enhancements in inadequate browsers should not be too complicated. The upside of this approach is that it will work with all browsers that don’t support the required functionality, old and new alike, and even those we aren’t aware of. 10.6.2 Undetectable Features Some features are hard to detect. An example can be found in how Internet Ex- plorer 6 renders certain replaced elements, such as select lists. Displaying another element over such a list will cause the list to show through the overlaid element. The quirk can be fixed by layering an iframe behind the overlay. Even if we cannot detect this problem, the fix is not known to cause problems in other browsers, and so can be safely employed in all browsers. If the fix to a problem won’t have ill effects in any browsers, applying the fix for everyone can often be simpler than de- tecting the problem. Before applying a fix preemptively, it’s a good idea to consider performance implications. Designing the problem away is another technique that is highly effective at avoiding cross-browser woes. For instance, IE’s implementation of getElement- ById will gladly return elements whose name property matches the provided id. This problem is simple to detect and work around, yet it is even simpler to make sure HTML elements never use ids that match some name property on the page, perhaps by prefixing ids. 10.7 Summary In this chapter we dove into feature detection, the most reliable and future proof technique available for writing cross-browser JavaScript. Browser sniffing in various forms has several pitfalls, and cannot be trusted. Not only is this technique unreliable and brittle, but it also requires knowledge about specific browsers in a way that make it a maintainability nightmare.Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. From the Library of WoweBook.Com 10.7 Summary 215 Feature detection—self testing code—was explored as an alternative to browser sniffing, and we ...