Keith Wood

Author
+ Follow
since Aug 28, 2012
Keith likes ...
jQuery
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
6
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Keith Wood

Thanks, that looks useful. It's a pity it isn't more widely supported yet.
Hi Rob

In HTML5 is it possible to synchronise audio or video with JavaScript actions? I have a page that drives a SVG animation from JavaScript that I want to synch with some music. But currently all I can do is start them at the same time and hope for the best.
Can you show the code you are using? Or provide the URL of a page that demonstrates the problem?
prop is the correct function to call. However, I suspect that the field you are trying to disable is part of the new content that comes from the load call. If that is the case, then you must only try to access it in the completed callback from the load.

Maybe the styling is overridden by other more specific rules. Can you provide the URL of a page that demonstrates the problem?

BTW, you might want to change 'Class' to 'class' just to be sure.
If you were to use jQuery for this the page would look like the following. Position the new image (line 30) at the top right via CSS (line 11). Load jQuery (line 17) and add a click handler to the close button (line 20).

Why are you adding a window.load callback within the document.ready one? The former should be unnecessary.

At the moment you are adding a document.keypress handler every time the window.keypress event is triggered. As above, you should probably remove the window.keypress handler and just keep the other one.
Thank you all for joining in the promotion and congratulations to the winners. I hope you can find something interesting and useful in this book.
The principle behind the noConflict function is to return the $ variable to its original value, i.e. prior to loading jQuery. This can be used with multiple versions of jQuery itself. The process would load the first version of jQuery and then any plugins that rely upon it. Next load the second version of jQuery and any plugins that require it. Then call noConflict to return $ to the first version and to assign a new variable to refer to the second version. Thereafter use the variables jQuery and the new one to refer to the different versions. Something like this:

I think you should include the version number in the file reference - in the path if not in the file name itself. As you note, this provides simple and clear documentation about which version is used/required for the page and helps to avoid using a different version that may or may not include a particular function. Most server-side frameworks let you include common snippets into your pages, so you should be able to have an include file that lists the JavaScript libraries and then only have to change it in one place.

At least jQuery and jQuery UI include version numbers that you can check if necessary - $.fn.jquery and $.ui.version respectively - although testing for the actual function/attribute may be a safer option. Maybe there should be a common mechanism to enquire about the version of a particular plugin. A compatibility wrapper can be useful to help users upgrade to a newer version, and is only required when older (deprecated) functionality is still required. Those users that follow the upgrade path can ignore it.
I haven't seen any details on this as yet - so the book doesn't cover it so far.
By "extending jQuery" I mean the writing of a section of code in the form of a plugin that can easily be reused on many pages. As Bear said, this lets jQuery concentrate on the functionality used by most people without bloating the library with rarely used abilities. The plugins integrate with fully into the normal jQuery processing and can take advantage of its other capabilities. The benefits of creating a plugin include consistency of appearance and behaviour across your Web site and reduced maintenance as there is only a single copy of the code to test and update.

You can extend existing plugins and override or add functionality to them - some more easily than others depending of how they are written. jQuery UI is designed to be extensible - most of its plugins extend its Widget module, or those that interact with mouse drags extend the Mouse module. You can enhance one of the jQuery UI widgets by using it as the basis for your new plugin.

Some plugins add their own internal extension points. For example, the Validation plugin lets you add new validation rules and class rules. My Calculator plugin lets you add new buttons/functions to it. However, these are isolated examples and each plugin does this its own way.

Versioning of plugins is always a problem - even just with jQuery itself. At least with jQuery and jQuery UI there is a built-in version number that you can check - $.fn.jquery and $.ui.version respectively. Most plugins don't provide this facility. Maybe this should be added to the list of best practices.
I haven't used Dojo but have found jQuery very easy to use. The writers of jQuery recognised that jQuery couldn't and shouldn't do everything and so included numerous extension points so that additional functionality could be integrated into the normal jQuery processing. You can see the result of this in the large third-party plugin community, so many requirements are already available as plugins.
There have been lots of changes in jQuery between 1.3 and 1.8, including many performance gains, Ajax enhancements, a Sizzle selector engine update, new event delegation, and animation changes.

You can now extend many aspects of jQuery. Most plugins add functions that integrate into the processing of collections of DOM elements, such as graphical sliders, datepickers, etc. Other plugins extend jQuery directly to provide utility or function plugins, such as for cookie processing. In addition you can add custom selectors, animations for non-numeric values, Ajax transporters and converters, and custom events. The only limit is your imagination.
I haven't looked at these other libraries - I've been happy using jQuery since I first discovered it. So, the book doesn't discuss these either - it is for those that want to use jQuery to a greater extent.