A few features that jQuery makes available to page authors are available not via methods or functions but as properties defined on $. In the past, several jQuery plugin authors have relied on these features to develop their plugins. But as will be evident in a few pages, some of them have been deprecated and their use isn’t recommended.
jQuery 3: Properties removed
jQuery 3 gets rid of the already deprecated context, support, and selector properties. If you’re still using them in your project or you’re employing a plugin that relies on one or more of them, upgrading to jQuery 3 will break your code.
The jQuery properties available are these:
- $.fx.off —Enables or disables effects
- $.fx.interval —Changes the rate at which animations fire
- $.support —Details supported features (for internal use only)
For the curious: the $.browser property
Before version 1.9 jQuery offered a set of properties that developers used for branching their code (performing different operations based on the value of a given property). They were set up when the library was loaded, making them available even before any ready handlers had executed. They were defined as properties of $.browser. The flags available were msie, mozilla, webkit, safari, and opera.
Let’s examine these properties, starting by looking at how jQuery lets you disable animations.
Disabling animations
There may be times when you want to conditionally disable animations in a page that includes various animated effects. You might do so because you’ve detected that the platform or device is unlikely to deal with them well, or perhaps for accessibility reasons. For example, you might want to completely disable animations on low-resource mobile devices because the effects will be sluggish, resulting in a bad experience for the user. When you detect that you’re in an animation-adverse environment or that you don’t need them, you can set the value of $.fx.off to true.
This will not suppress any effects you’ve used on the page; it’ll simply disable the animation of those effects. For example, the fade effects will show and hide the elements immediately, without the intervening animations. Similarly, calls to the animate() method will set the CSS properties to the specified final values without animating them.
The $.fx.off flag, together with $.fx.interval discussed in the next section, is a read/write flag, which means you can read as well as set its values. On the contrary, $.support is meant to be read-only.
Changing the animations rate
Like any library that performs animations, jQuery has a property called $.fx.interval to set the rate at which animations fire. As you know, an animation is made up of a progression of steps that, seen as a whole, create the effect. If a comparison helps, you can think of a movie as a progression of photos shown at a regular pace. Using the $.fx.interval property, you can tweak the pace at which the steps are performed.
The $.fx.interval property is a read/write property and its value is expressed in milliseconds, with its default value set to 13. The latter is not random, but it’s a reasoned choice guided by a trade-off between having smooth animations while not stressing the CPU.
In a heavily animation-driven scenario, you may want to try to tweak this value a bit to create even smoother animations. You can do so by setting the value of $.fx.interval to a number less than 13. Modifying the rate can result in nicer effects in some browsers, but on low-resource devices or not-so-fast browser engines (for example, those in the older versions of Internet Explorer) this may not be true. On these browsers, not only might you not have evident advantages, but you may also notice worse performance because of the stress of the CPU.
That being said, imagine that you want to set the value of $.fx.interval to 10. To do so, you can write
$.fx.interval = 10;In the same way that you can set a lower value, you can increase it. This change may become handy if you’re working on a web page that’s stressing the CPU—for example, if several animations are running at the same time or because the page performs CPU-intensive operations while running some animations. Because animations aren’t as important as performing tasks, you can decide to slow down the rate at which animations fire to help the CPU. For instance, you may set the value to 100 so that the refresh happens 10 times each second:
$.fx.interval = 100;To allow you to see the difference in how animations run depending on the value of $.fx.interval, we created a demo just for you that you can find in the file lesson-9/$.fx.interval.html and also as a JS Bin.
Now that we’ve finished with properties that deal with animations, let’s quickly examine the one that provides information on the environment provided by the user agent.
The $.support property
jQuery has a property named $.support that stores the result of some feature testing that is of interest for the library. This property allows jQuery to know which features are supported and which are not supported in the browser and act accordingly. This property is intended for jQuery’s internal consumption only and it’s deprecated since jQuery 1.9, so we strongly encourage you to avoid using it. Some examples of the property exposed, now or in the past, are boxModels, cssFloat, html5Clone, cors, and opacity.
Relying on the $.support object is a bad idea because its properties may be removed at any time without notice when they’re no longer needed internally. The deletion of these properties is done to improve the performance of the library’s load because it avoids the need to perform some tests on the browser. In this app we decided to mention it because you might use an old but good plugin that relies on the $.support property.
This object is also one of the few cases where there’s a difference between the branches of jQuery; the 1.x branch has more properties than the 2.x branch, and Compat 3.x has more properties than 3.x. For example, 1.x has ownLast, inlineBlockNeedsLayout, and deleteExpando that 2.x doesn’t have.
Feature detection with Modernizr
If your project needs to act in a different way based on the features supported by a given browser, you should employ an approach known as feature detection. Instead of detecting the browser used by the user and then trying to determine whether features are supported or not (an approach known as browser detection), feature detection requires that you detect for the presence of the features directly.
For a project where you need to test for several features, we strongly encourage the use of an external library created for this specific purpose. The most famous and most used library is Modernizr. This library detects the availability of native support for features that stem from the HTML5 and CSS3 specifications.
Modernizr tests for features that are implemented in at least one major browser (there’s no point in testing for a feature that nobody supports, right?) but usually supported in two or more. The following is a list of what Modernizr does for you:
- Tests for support of over 40 features in a few milliseconds
- Creates a JavaScript object (named Modernizr) containing the results of the tests as Boolean properties
- Adds classes to the html element describing what features are implemented
- Provides a script loader to allow you to use polyfills to backfill functionality in old browsers
- Allows using the new HTML5 sectioning elements in older versions of Internet Explorer
What’s a polyfill?
A polyfill is a piece of code (or plugin) that provides the technology that developers expect the browser to provide natively. The term was created in 2010 by Remy Sharp, a well-known JavaScript developer and founder of the Full Frontal conference. You can find more information about how and why the term was created in the original Remy Sharp post “What is a Polyfill?”.
With this section we’ve covered the last property left, so we’re now ready to move along and start discussing jQuery’s utility functions.
Using other libraries with jQuery
The definition of the $ global name is usually the largest point of contention and conflict when using other libraries on the same page as jQuery. As you know, jQuery uses $ as an alias for the jQuery name, which is used for every feature that jQuery exposes. But other libraries, most notably Prototype, use the $ name as well.
jQuery provides the $.noConflict() utility function to relinquish control of the $ identifier to whatever other library might wish to use it. The syntax of this function is as follows.
$ is an alias for jQuery, so all of jQuery’s functionality is still available after the application of $.noConflict(), albeit by using the jQuery property of the window object. But don’t worry. You can still save typing some characters by defining a new, short identifier. You can compensate for the loss of the brief—yet beloved—$, defining your own shorter but nonconflicting alias for jQuery, such as
var $j = jQuery;In case you need to give up both the $ and the jQuery identifier, you can still use the jQuery methods and utility functions by using the $.noConflict() utility function and storing the returned value (the jQuery library) into another global property:
window.$new = $.noConflict(true);Once this statement is executed, you’re able to use the jQuery methods by employing the $new property just created (for example, $new('p').find('a')).
A design pattern you may often see employed, called Immediately-Invoked Function Expression (IIFE), consists of creating an environment where the $ identifier is scoped to refer to the jQuery object. (If you’ve never heard of this pattern or need a refresher, please review the appendix.) This technique is commonly used in several situations: to extend jQuery, particularly by plugin authors; to simulate private variables; and to deal with closures. In the case of plugin authors, this is useful because they can’t make any assumptions regarding whether page authors have called $.noConflict() and, most certainly, they can’t subvert the wishes of the page authors by calling it themselves.
We’ll cover this pattern in detail in the appendix. For the moment, understand that if you write
(function($) {
// Function body here
})(jQuery);you can safely use the $ identifier inside the function body, regardless of whether it’s already defined by Prototype or some other library outside of the function. Pretty nifty, isn’t it?
Let’s prove what we’ve discussed in this section with a simple test. For the first part of the test, examine the HTML document in the following listing (available in lesson-9/overriding.$.test.1.html).
Listing 9.1. Overriding $ test 1
In this example, you import jQuery, which defines the global names jQuery and its alias $. You then redefine the global $ variable to a string value 
, overriding the jQuery definition. You replace $ with a simple string value for simplicity within this example, but it could be redefined by including another library such as Prototype.
Then you try to attach a handler to a button defined in the markup of the page 
. Inside the handler you call the JavaScript alert() function to show a success message on the screen 
. If something goes wrong, you show a failure message 
.
Loading this page in a browser proves that you see the failure alert displayed, as shown in figure 9.1. The reason for the failure is that you’ve redefined the value of the $ identifier. Moreover, the button doesn’t trigger any action because $ was reassigned before the click handler was defined.
Figure 9.1. The page shows that $ has been replaced. The value is “Hello world!” because its redefinition has taken effect.
Now you’ll make one slight change to this example to be able to use $ safely. The following code shows only the portion of the code within the try block that has been modified. The change is highlighted in bold for your convenience. The full code of this example can be found in the file lesson-9/overriding.$.test.2.html of the source provided with this app:
try {
(function($) {
$('#button-test').on('click', function() {
alert('$ is an alias for jQuery');
});
})(jQuery);
} catch (ex) {The only change you make is to wrap the statement where you attached the handler with an IIFE and pass the window.jQuery property to it. When you load this changed version and click the button, you’ll see that the button now works and a different message is displayed, as shown in figure 9.2.
Figure 9.2. The alert now displays the success message set inside the handler.
Changing the code as shown in the previous example lets you use the $ shortcut as an alias for jQuery, while preserving the original, global value of $ (the string "Hello world!" in this case). Now let’s see how you can restore the value of $ to whatever it was before including the jQuery library using the $.noConflict() method. A typical situation where you’d use this method is shown in the next listing and is available in the file lesson-9/$.noConflict.html and as a JS Bin.
Listing 9.2. Using the $.noConflict() method
In this example, you create a dummy custom library having just one method: customLog(). You could import any library that takes advantage of the $ shortcut, like Prototype, in place of the dummy library, but you want to avoid adding another real library for the sake of simplicity. Then you import the jQuery library that replaces the library stored in $. Next you check that the dummy library has been replaced by testing that the customLog() method isn’t defined (jQuery doesn’t have such a method) .
In the next line of code, you restore the value of $ to whatever it was before the import of the jQuery library, calling jQuery’s noConflict() function . Finally, you test again if you can access the customLog() method via the $ shortcut 
and print a message on the console using this method 
.
Now that you’ve seen how you can use jQuery to avoid any interference with other libraries, it’s time to learn the other jQuery utility functions.
Leave a Reply