Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I recently read in the jQuery documentation that:

The .ready() method is generally incompatible with the body onload attribute. If load must be used, either do not use .ready() or use jQuery's .load() method to attach load event handlers to the window or to more specific items, like images.

As it turns out, the onload attribute is commonly used in SharePoint, via _spBodyOnLoadFunctionNames.

I'd be interested to know if anybody has experienced such incompatibilities, and can confirm that there's actually a risk when using document.ready in the context of SharePoint.

share|improve this question
add comment

6 Answers

up vote 6 down vote accepted

I have some specific examples on my blog but to answer this in short - from my experience, you can use them interchangeably, but it depends heavily on what you are doing (and when you want events to happen). If you are deploying a control that is completely yours and you are not doing DOM manipulation or dynamic width/height adjustments, you should be able to use jQuery(document).ready(...) - however if you're interacting with third party or OOB functionality or manipulating the DOM, you should lean on _spBodyOnLoadFunctionNames instead.

If you want to read some detailed examples, please read my post and the detailed answer to this on my blog (link above) - but in short - _spBodyOnLoadFunctionNames runs after the DOM is loaded and rendered (usually after all assets, including images are done loading). jQuery(document)ready(...) runs as soon as the DOM is rendered (I ran into this and tested it when implementing a custom top-nav - with a 3rd party plugin loading images from another server).

Another note - always try to use jQuery.noConflict(); when working within SharePoint. In specific instances, jQuery doesn't interact well with SharePoint's $(...). You can read more about this on my blog (www.stephanrocks.com), and about jQuery.noConflict() on jQuery's site.

Hope this helps :) If you can be more specific about what you're doing, maybe I can help you decide which to use.

Have a great day everyone!

Stephan.

share|improve this answer
    
I read that page - there is some good, useful information there. Thanks, Mr. Robberts. –  BGM Dec 17 '12 at 16:14
add comment

For what it's worth, my employer's MOSS 2007 standard master page uses $(document).ready() for several functions, and I use it all the time with custom master pages and the default master page without any conflicts.

share|improve this answer
    
In the past, I never clearly identified any conflict either. But on occasions the dynamic scrollbar wouldn't work, and I didn't know why. Reloading the page would fix the issue. I am glad Stephan provided specific examples, next time it happens I'll sure want to profile the page JavaScript! –  Christophe Mar 19 '12 at 23:09
add comment

There is a difference in jQuery(document).ready() and jQuery(window).load(). The SharePoint _spBodyOnLoadFunctionNames is like jQuery(window).load(), not jQuery(document).ready().

In most cases all you need is jQuery(document).ready() which is fired when DOM is present. But sometimes, like when resizing pictures just DOM is not sufficient, you need to have loaded content.

To sum up, use jQuery(document).ready() if you want to change properties, add classes, hide, show elements. And use jQuery(window).load() (or _spBodyOnLoadFunctionNames) if you need to wait until resources (the whole window) are loaded.

share|improve this answer
    
As I already answered (to Marc), using onload is not my choice, it's what SharePoint does. My question is not about using one vs. the other, but about using both. –  Christophe Mar 1 '12 at 22:36
add comment

http://www.stephanrocks.com/2011/10/05/_spbodyonloadfunctionnames-in-sharepoint-vs-jquerys-document-ready/

share|improve this answer
    
Thanks! I have left a message to the author and will report back. –  Christophe Mar 1 '12 at 23:12
    
I am still trying to get some insight from the blog author. I haven't yet come across a case where the page breaks. –  Christophe Mar 17 '12 at 18:09
    
Alex, the author has posted an answer directly here. I really appreciate your reply, which sent me in the right direction. –  Christophe Mar 18 '12 at 2:14
    
We prefer it if you post the essence of the solution here and include the link just for reference. If the link goes bad the answer is then still useful. Thanks. –  SPDoctor Dec 17 '12 at 22:21
add comment

Just as a matter of interest. It's not best practice in any way to interfere with the Sharepoint Event Load model as this might have unexpected behaviour. To this end, Sharepoint has made available a JS function which allows us to load scripts using the "supported" Sharepoint way. Herewith the sample :

    <script type="text/javascript">

    //Function below will insert your script into the correct location    
    ExecuteOrDelayUntilScriptLoaded(initializeScript, "sp.js");

    function initializeScript() {
     alert('Loaded');
    }

   </script>
share|improve this answer
3  
Thanks for the comment. This is fine for scripts, but sometimes you also need to wait for DOM elements. In such cases the above function doesn't help. –  Christophe Mar 1 '12 at 22:40
add comment

My question is why you would ever want to use both. Simply choose one and stick with it. IMO, if you have jQuery loaded, always use $(document).ready().

share|improve this answer
1  
He's curious because that's how one gains knowledge. –  KyleM Mar 1 '12 at 0:07
1  
Marc, look at the source code of a SharePoint page, you'll see that SharePoint uses onload for its own JavaScript libraries, this is not our choice (unless you get rid of the SharePoint libraries). –  Christophe Mar 1 '12 at 0:31
    
I just checked your company website home page and it uses both. Apparently no conflict to report here :-) –  Christophe Mar 1 '12 at 0:38
    
Correct. I've never seen the conflict. –  Marc D Anderson Mar 1 '12 at 0:54
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.