jQuery API

jQuery.support

jQuery.support Returns: Object

Description: A collection of properties that represent the presence of different browser features or bugs.

  • version added: 1.3jQuery.support

Rather than using $.browser to detect the current user agent and alter the page presentation based on which browser is running, it is a good practice to perform feature detection. This means that prior to executing code which relies on a browser feature, we test to ensure that the feature works properly. To make this process simpler, jQuery performs many such tests and makes the results available to us as properties of the jQuery.support object.

The values of all the support properties are determined using feature detection (and do not use any form of browser sniffing).

Following are a few resources that explain how feature detection works:

While jQuery includes a number of properties, developers should feel free to add their own as their needs dictate. Many of the jQuery.support properties are rather low-level, so they are most useful for plugin and jQuery core development, rather than general day-to-day development. Since jQuery requires these tests internally, they must be performed on every page load; for that reason this list is kept short and limited to features needed by jQuery itself.

The tests included in jQuery.support are as follows:

  • ajax is equal to true if a browser is able to create an XMLHttpRequest object.
  • boxModel is equal to true if the page is rendering according to the W3C CSS Box Model (is currently false in IE 6 and 7 when they are in Quirks Mode). This property is null until document ready occurs.
  • changeBubbles is equal to true if the change event bubbles up the DOM tree, as required by the W3C DOM event model. (It is currently false in IE, and jQuery simulates bubbling).
  • checkClone is equal to true if a browser correctly clones the checked state of radio buttons or checkboxes in document fragments.
  • checkOn is equal to true if the value of a checkbox defaults to "on" when no value is specified.
  • cors is equal to true if a browser can create an XMLHttpRequest object and if that XMLHttpRequest object has a withCredentials property. To enable cross-domain requests in environments that do not support cors yet but do allow cross-domain XHR requests (windows gadget, etc), set $.support.cors = true;. CORS WD
  • cssFloat is equal to true if the name of the property containing the CSS float value is .cssFloat, as defined in the CSS Spec. (It is currently false in IE, it uses styleFloat instead).
  • hrefNormalized is equal to true if the .getAttribute() method retrieves the href attribute of elements unchanged, rather than normalizing it to a fully-qualified URL. (It is currently false in IE, the URLs are normalized).
  • htmlSerialize is equal to true if the browser is able to serialize/insert <link> elements using the .innerHTML property of elements. (is currently false in IE).
  • leadingWhitespace is equal to true if the browser inserts content with .innerHTML exactly as provided—specifically, if leading whitespace characters are preserved. (It is currently false in IE 6-8).
  • noCloneChecked is equal to true if cloned DOM elements copy over the state of the .checked expando. (It is currently false in IE). (Added in jQuery 1.5.1)
  • noCloneEvent is equal to true if cloned DOM elements are created without event handlers (that is, if the event handlers on the source element are not cloned). (It is currently false in IE).
  • opacity is equal to true if a browser can properly interpret the opacity style property. (It is currently false in IE, it uses alpha filters instead).
  • optDisabled is equal to true if option elements within disabled select elements are not automatically marked as disabled.
  • optSelected is equal to true if an <option> element that is selected by default has a working selected property.
  • scriptEval() is equal to true if inline scripts are automatically evaluated and executed when inserted into the document using standard DOM manipulation methods such as .appendChild() and .createTextNode(). (It is currently false in IE, it uses .text to insert executable scripts).
    Note: No longer supported; removed in jQuery 1.6. Prior to jQuery 1.5.1, the scriptEval() method was the static scriptEval property. The change to a method allowed the test to be deferred until first use to prevent content security policy inline-script violations.
  • style is equal to true if inline styles for an element can be accessed through the DOM attribute called style, as required by the DOM Level 2 specification. In this case, .getAttribute('style') can retrieve this value; in Internet Explorer, .cssText is used for this purpose.
  • submitBubbles is equal to true if the submit event bubbles up the DOM tree, as required by the W3C DOM event model. (It is currently false in IE, and jQuery simulates bubbling).
  • tbody is equal to true if an empty <table> element can exist without a <tbody> element. According to the HTML specification, this sub-element is optional, so the property should be true in a fully-compliant browser. If false, we must account for the possibility of the browser injecting <tbody> tags implicitly. (It is currently false in IE, which automatically inserts tbody if it is not present in a string assigned to innerHTML).

Examples:

Example: Returns the box model for the iframe.

<!DOCTYPE html>
<html>
<head>
  <style>
  p { color:blue; margin:20px; }
  span { color:red; }
  </style>
  <script src="http://code.jquery.com/jquery-latest.js"></script>
</head>
<body>
  <p>
  </p>
<script>

    $("p").html("This frame uses the W3C box model: <span>" +
                jQuery.support.boxModel + "</span>");

</script>

</body>
</html>

Demo:

Example: Returns false if the page is in QuirksMode in Internet Explorer

jQuery.support.boxModel

Result:

false

Support and Contributions

Need help with jQuery.support or have a question about it? Visit the jQuery Forum or the #jquery channel on irc.freenode.net.

Think you've discovered a jQuery bug related to jQuery.support? Report it to the jQuery core team.

Found a problem with this documentation? Report it to the jQuery API team.

* All fields are required
  • http://blog.maxaller.name/ Max

    I like the idea of feature detection, but suggesting that it’s the end-all-be-all solution for cross-browser compatibility just isn’t accurate. How do I tell if I need to create an iframe shim over the top of form and flash elements in order to display content over form/flash elements? jQuery.support can’t help with that, we have to use jQuery.browser. Or what about detecting if a browser supports html5 attributes async or defer? Have to check for browser there, too.

    A lot of people add CSS on to DOM nodes using jQuery — that’s a big use case. But while CSS interpretations vary by browser (and much more than by box model), we’re not “supposed” to use jQuery to determine which browser we’re running? That’s just…weird.

  • http://www.learningjquery.com/ Karl Swedberg

    Of course there are exceptions to the rule.

  • Xavier

    Could be usefull to have in jQuery more support :
    $.support.colorRgba
    $.support.colorHsl(a)
    $.support.alpha
    $.support.fontFace
    $.support.transition
    $.support.transform
    With those new properties we can delegate more to the css core and add prevention for olds navigators.

  • http://www.learningjquery.com/ Karl Swedberg

    A plugin would be a better place for adding such support. Even better: Modernizr.

  • RobH

    Note: objectAll is not detected in v1.4. This means it is not possible, as far as I can tell, to detect IE6 using jQuery.support.

    The ‘naughty’ way: jQuery.browser.msie && jQuery.browser.version == 6

  • Hans

    hrefNormalized: Is equal to true if the .getAttribute() method retrieves the href attribute of elements unchanged, rather than normalizing it to a fully-qualified URL. (It is currently false in IE, the URLs are normalized).

    This is counter-intuitive. hrefNormalized is true when it is not normalized and vice-versa. A more appropriate name would then be hrefNotNormalized.

  • Anonymous

    Feature detection sounds all fine and dandy, but when I am writing some code that doesn’t work in a certain browser, the quickest method is browser detection.

    Horizontally centering an element using auto margins works for all browsers except IE. What feature do I test for? I have no idea. But I do know which browser it doesn’t work in.

    I can see why feature detection would be useful in certain situations eg. if a browser is in quirks/strict mode. The best compromise would be to utilise both methods.

    In light of this “We recommend against using this property, please try to use feature detection instead” should be removed from the jQuery.browser documentation page. It is misleading.

  • http://twitter.com/mista_k Vladimir Kuznetsov

    I want to present an addition to the existing properties of this object. There were many requests to get a way to detect the IE6. For those who need it the most, I propose to use the discovery of specific CSS rules.

    http://noteskeeper.ru/article/detect-ie6-via-css-selector/

    The article was written in Russian, but I hope the code is clean and clear without comments.

  • http://twitter.com/ihumanable Matt Nowack

    I agree with Hans, the hrefNormalized behavior seems backwards. I understand the underlying rationale, if something complies with spec then it returns true, but it’s still counter intuitive. tbody seems to suffer the same fate, $.support.tbody == true if the browser does NOT insert a tbody tag. It’s a bit confusing, maybe changing the name to $.support.preserveHref and $.support.optionalTbody would be an acceptable solution.

    It does seem like a good idea to have $.support.* return true if the thing being tested conforms to spec, but they should be named in such a way that the code makes sense.

  • http://www.victusspiritus.com/ Mark Essel

    Talk about bad habits, I haven’t even done any cross browser checking with my rough drafts. If it looks good in Chrome and Firefox I call it good enough. I’m afraid of the IE interpretation, so I’ve delayed worrying about this as long as possible.

  • http://twitter.com/paul_irish Paul Irish

    I wrote some $.support augmentations for detecting css support of display:'table' and 'table-cell':
    http://gist.github.com/362170

  • http://paulirish.com Paul Irish

    I’ve written a test that checks for centering support with `margin:0 auto`:
    http://gist.github.com/362170

    (and `display: table(-cell)` and `position:fixed`)
    hope this works for ya.

  • Augur

    So, the only exceptions that I am seeing here are for IE. Basically it seems we should just collectively give the middle finger to IE and enjoy the power that WebKit and Mozilla give us. Why do we have to dumb down and hack our code to accommodate the albatross of browsers? Let IE fall by the way side if they will not play on the same standards as everyone else. There is absolutely no reason that this browser should be #1 with the exception that Grandma gets it already installed on her mail ordered Dell. Can’t we just lobby these companies to include a webkit or mozilla browser as well?

  • http://jonraasch.com/ Jon Raasch

    Any talk of extending this for CSS3 features? Detecting CSS3 transition support would be particularly useful (to support it with jQuery.animate())

  • http://jonraasch.com/ Jon Raasch

    I put together a jQuery.support hack to check CSS3 transition support – http://gist.github.com/373874

  • Anonymous

    HTML5?

    How about detection if the browser can use HTML5?
    HTML5 = $.support.HTML5;
    HTML5.video = 1 || 0;
    HTML5.canvas = 1 || 0;
    HTML5.audio = 1 || 0;
    HTML5.(*) = 1 || 0;

    html5enabled = parseInt(
    (typeof HTMLVideoElement != undefined ? 1 : 0) + “” +
    (typeof HTMLAudioElement != undefined ? 1 : 0) + “” +
    (typeof HTMLCanvasElement != undefined ? 1 : 0)
    ) == 111 ? 1 : 0;

    I know that there are many html5 elements but this is just a starter of html5 detection..

  • http://twitter.com/GeeROC Rocco Georgi

    +1
    I was thinking about the same thing yesterday writing a recap of our HTML5/CSS3 meetup (in Frankfurt) – we had someone present Modernizr.com – this would be great to have as a jQuery plugin.

  • Mark

    Yes, All IE return false for “JQuery.support.objectAll”

  • rglazebrook

    I wrote a script that adds CSS3 border-radius support information to the jQuery.support object: http://www.cssnewbie.com/test-for-border-radius…

  • Tom

    Not all differences in browser behavior are due to differences in the feature set. Sometimes browsers just display things a few pixels differently, and whatever you are doing to compensate for that may need to carry over into slight variations in the parameters one is passing in Javascript. So it seems to me as though some form of more direct browser detection is needed. The hack would be to know which, if any, features jQuery can detect that are unique to specific browsers.

  • Bjorn Johnson

    This is a fantastic point. The deprecation warning in the documentation is based more on theology than practice. Writing your own plugin to test for certain features is fine and even great, but if your requirement says “For IE do this…”, then it makes perfect sense to use jQuery.browser. You could say, “Well, that’s a dumb requirement”. But not everyone has the leeway or time to explain to clients and colleagues why their requirements are silly.

    It’s like trying to find out “where someone works” by asking them the address of their workplace. In some cases, the address IS really what you want to know, to plug into your GPS or whatever. In other cases, you’re just looking for the name of the company. To issue a broad statement that you should only ask for an address even if you’re just looking for the name of the company would be making something difficult that need not be that way.

  • Jack Fuchs

    I wrote a $.support extension for detecting css property support.

    http://gist.github.com/556448

  • http://twitter.com/benpbarnett Ben Barnett

    I've written a plugin to enhance $.animate, making it automatically use CSS3 transitions when they're available. It uses some of your code Jon so thought you might be interested: http://playground.benbarnett.net/jquery-animate…

  • Foxdanni

    what about $.support.boxShadow …

  • http://www.learningjquery.com/ Karl Swedberg

    As with all the other questions about CSS3 features, the best solution is to use a script like modernizr or include one of the $.support extension plugins floating around. It’s doubtful that jQuery will roll these into core any time soon.

  • Tgr

    jQuery 1.4.2 also has jQuery.support.submitBubbles and jQuery.support.changeBubbles (true if the submit/change events bubble up). jQuery uses workarounds to make event delegation work even when bubbling of the event is not natively supported, but this can lead to unexpected side effects (for one, the order in which event handlers normally run should not be relied upon).

  • Pmithrandir

    I totaly agree on your point. I don’t really care about feature, I want to know in which browser it works or not, customers oriented dev you know.

    I can understand why the current $.browser is not safe, because it use the user agents… but the solution is not to create another method that does a different job. The solution is to use this new method and to upgrade the current $.browser function to check functionality and properties in place on user agent to detect the browser.

    Check on mootools code, I think they do that since 3 or 4 years…

  • Jack Fuchs

    You could use my extension, http://gist.github.com/556448

  • Guest

    I know what you mean…..

  • Foldericon

    I played around with 3d webkit transitions. Now I want to detect if the browser supports it (currently safari only) and if not, I want to use 2d transitions instead. How can I check for 3d transitions and (if possible) it should work in future browser versions too.

  • Jack Fuchs

    You could use my extension for that, http://gist.github.com/556448

  • NetscapePizza

    Yeah, this kinda sucks. I just want to detect Safari5 to offer HTML5 fullscreen in that case.
    We can pretend browsers no longer matter and it's features that matter, but it just isn't true.

  • NetscapePizza

    Yeah, this kinda sucks. I just want to detect Safari5 to offer HTML5 fullscreen in that case.
    We can pretend browsers no longer matter and it's features that matter, but it just isn't true.

  • Joshua Robison

    I do not agree that feature detection is best practice. I think that many people are making a serious mistake here.

    The idea of feature detection is like the idea of those laser disks movies long ago.
    Many of you are saying , “what laser disk movies?” and to that I reply , “exactly!”

    Let me tell you right now that best practice is to use browser detection and dish out css for each browser. NOT FOR EACH VERSION.

    for example :

    moz-name.css
    webkit-name.css
    o-name.css
    ie-name.css
    ios-name.css
    android-name.css

    then you just tell your users that they need to upgrade to the latest browser, depending on which one they are using.

    Feature detection should then be placed inside these browsers to help distinguish between MAC/PC etc.

    THE PROBLEM WITH FEATURE DETECTION,
    and the reason it will never gain popularity, is that it can not account for SO MANY problems and there is little support when you run into them. Plus there will be more bugs in the future and we will have to sit around and wait for someone to come out with a cool feature detect plugin to recognize that bug. No company has time or money to waist on this.

    SIMPLE SOLUTION
    When a new browser comes out, check it and make sure your css is up to date with it and then MAKE USERS feel bad for not upgrading their browser like they should. They should understand that if the site does not look pretty it is because THEIR COMPUTER AND BROWSER ARE TOO OLD. And they need to upgrade. THE USER SHOULD UNDERSTAND THAT THEY ARE THE ONES TO BLAME.

    I suggest a lightbox pop up that says,

    “unfortunately your computer or browser are out of date.
    You will not be able to view the full content of this site,
    but you may click HERE for a minified version.
    We strongly suggest that you upgrade and use one of the following browsers
    firefox, mozilla, ie, opera, safari”

    This way the user can still view the buggy minified version if they want, and you don't loose business and they may upgrade their browser in the future.

    As for FEATURE DETECTION, it will be deprecated and you will see more and more people moving to the BEST PRACTICE that I have described here.

  • bodine

    Why was opacity chosen instead?

  • http://www.facecash.com Allan Bonadio

    Re: feature detection
    I get it that there's too many feature differences to do a feature detection boolean for them all. So, if the handful of most common feature differences have a boolean, I'll go and use it, and it'll work right when such feature difference is fixed to the standard (or re-broken).

    Otherwise each programmer has to struggle independently to figure out which versions of what browser do what.

    For everything else, yeah, I'll just say if($.browser.msie) and hack something. And try to write code that'll still work even if the bug is fixed someday.

  • http://twitter.com/AraGarabedian Ara Garabedian

    One simple fix for IE detection is to use Paul Irish's method of wrapping the html tag with a conditional comment, then doing your jquery as normal using the IE version specific class: http://paulirish.com/2008/cond…/ (this method is used in the html 5 boilerplate template). Not a 'catch all' solution for every browser, just for IE. Hope it helps somewhat.