JQuery_ Novice to Ninja - Earle Castledine [151]
If you use pure jQuery, most of these issues are taken care of internally, but if you’re dirtying your hands with some raw JavaScript, there’s a nifty mechanism for feature detection available via the support action. We looked at this in Chapter 6, but only briefly spoke of the options available. There are many. They all return a true or false value to indicate if they’re supported, which can then be used in an if/then/else block to provide support for both cases. For example:
var domObject = document.getElementById('content');
if ($.support.cssFloat) {
domObject.style.cssFloat = "left";
} else {
domObject.style.styleFloat = "left";
}
Here are the available properties:
boxModel
The boxModel property (which is initially set to null, and changed to true or false after the document has loaded) will be true if the browser renders in accordance with the W3C box model.
changeBubbles
Detecting browser features as they pertain to events can be a tricky business—it used to be a very common reason to do browser sniffing. Thankfully some clever people figured it all out, so now if you want to know if you can (reliably) react to the change event, you can check the changeBubbles property.
cssFloat
We saw the cssFloat in action in the example above. It detects whether the browser uses the cssFloat label to address the float style in JavaScript. (It’s impossible to simply float, because that’s a JavaScript keyword referring to floating-point numbers). Internet Explorer uses styleFloat instead of cssFloat.
hrefNormalized
Some browsers fiddle around with links that they’ve determined have been constructed incorrectly—which is a problem if it’s unexpected! The hrefNormalized property will return true if the browser modifies the links.
htmlSerialize
If you need to make sure that link elements (such as link and script tags) are serialized correctly when using innerHTML, you can use the htmlSerialize property. Internet Explorer has problems with this—and you’ll need to wrap the offending tags in your own wrapper elements if you want it to play nice.
leadingWhitespace
The leadingWhitespace option lets you know if the browser leaves the first node in a DOM child as whitespace or not. When innerHTML is used, Internet Explorer strips out the first child if it’s a whitespace text node; this can mess up your jQuery code if you’re relying on a set number of children.
noCloneEvent
When you clone a DOM node, some browsers will also clone the event handlers that are attached to it, while others won’t. If events aren’t cloned the noCloneEvent property will be true.
opacity
We’re all big fans of opacity: it makes sites look futuristic. Unfortunately some browsers are unable to play with opacity via JavaScript (of course, if you use jQuery you’re safe). The opacity property tests to see if the rendering engine understands opacity—otherwise you’ll need to resort to using the browser’s filters.
scriptEval
Browsers also behave differently with regard to executing scripts with injected script tags. The scriptEval property will let you know if it’s safe to inject via appendChild, or if you should use the script.text property.
style
To find the style currently applied to an element, you can use the getAttribute method and ask for style—in some browsers. To test whether or not getAttribute("style") will work on your user’s browser, you can check the style property.
submitBubbles
Another event you can check for is the submit event via the submitBubbles property. Internally, this uses the same feature detection tricks as changeBubbles.
tbody
And finally, in some browsers a tbody element will be automatically inserted into an empty table—which can mess up your DOM manipulations. To check whether you need to look out for this, there’s the tbody property. This will return true (confusingly) if you can have