That needs to change tonight. The code-editor is an appcache application so that it can be used offline. It only make sense for a code editor to be available offline. But what about the libraries used in the book?
I have been going back and forth between referencing libraries directly on the root URL:
<body></body> <script src="http://gamingJS.com/Three.js"></script> <script src="http://gamingJS.com/Detector.js"></script> <script src="http://gamingJS.com/physi.js"></script> <script src="http://gamingJS.com/ChromeFixes.js"></script> <script> // Code goes here... </script>Or referencing them in a versioned URL-space:
<body></body> <script src="http://gamingJS.com/52/Three.js"></script> <script src="http://gamingJS.com/52/Detector.js"></script> <script src="http://gamingJS.com/52/physi.js"></script> <script src="http://gamingJS.com/52/ChromeFixes.js"></script> <script> // Code goes here... </script>Obviously the latter is the more future proof of the two. If I were making this for a "real" site, I would probably opt for it. But since this is for a book (and a kids book at that), I think that conceptual simplicity has to win.
http://gamingJS.com/ice/Three.js. That would allow me to write
<script src="Three.js"></script>That has some appeal—especially from a simplicity standpoint. Although it is short, I think it is actually less conceptually simple. At some point in the book, I need to explain what these tags do. It's far easier to explain a URL than a relative URL.
So, after all of that, I am left with the web site proper holding the 3D libraries (
http://gamingJS.com/Three.js) and the embedded code-editor referencing them in the appcache manifest,
Once I push that out to gamingJS.com, I see the manifest pull in everything—even the libraries from the URL-space above the ICE editor (gamingJS.com/ice):
And, more importantly, I can use the editor offline:
So this seems to work fairly well. Even for the stuff that would otherwise be outside of the appcache application.