VSE+ wrote:FWIW, I came across a CDN fallback to local version method, that works...
Code: Select all
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js"></script>
<script type="text/javascript">
// <![CDATA[
!window.jQuery && document.write('<script type="text\/javascript" src="jquery-1.4.3.min.js"><\/script>');
// ]]>
</script>
This reminded me that we should put javascript at the bottom of pages. Hopefully both jquery itself and all of our code.
http://developer.yahoo.com/performance/ ... #js_bottom
As far as practical utility of the quoted fragment is concerned, I run ad blocking locally and my firefox renders itself useless when it is waiting for a connection or a reply from remote server and javascript is involved. In other words the above fragment on my computer, assuming ajax.googleapis.com was dropping all traffic sent to it, would hang page loading forever.
---
I have been staying out of the CDN debate until now but I do offer the following considerations:
1. We must include jquery locally. This is needed to support disconnected (from the internet) operation.
2. Because of #1 the decision is between having a local copy only or having local copy + CDN. Since the local copy is already essentially implemented, whether CDN will be an option or not depends on someone implementing it. In my opinion having CDN support is not a requirement for merging jquery into develop.
How to actually implement CDN seems to be tricky. I am not a big fan of telling admins to edit the code if they want a CDN. We are trying to move away from modifying core code and this in a step in the opposite direction. Perhaps we can simply provide a config variable (hidden or visible) where an admin can put the full path to where they want to get jquery from. This will let admin specify whichever version they want and whichever CDN they want, freeing us from having to maintain a list of CDNs as well as worrying about those CDNs not carrying versions that we use.