I wrote a new loader function called sh_highlightBody() that would enable SHJS from within the body, specifically useful for those of us adding SHJS to template-based sites or other sites that don't have access to the head or the body tag itself. This loader can be placed in the head or the body, and also sets the theme. You could use the theme loader (a separate function) from the body onload tag along with the standard sh_highlightDocument() function too.
I suspect it's best to more fully integrate these functions than to keep them separate, but I wanted to keep my own stuff outside of SHJS so upgrading is easier. My code is released under the GPL v3 (like SHJS) and you may credit me as "Adam Katz."
I also created a few new themes (also GPL v3), most of them by merely rotating the RGB values within other themes. I'm specifically proud of my "khopesh" theme for its WCAG-compliant contrast despite the limitations of my site design. You can see my themes demoed through the very same mechanism used to demo the rest of the themes, hosted on my site at http://khopesh.com/shjs-0.6 and you can see my notes about the whole process at http://khopesh.com/blog/adam-katz-musings/lifetype-highlight
loader function for simplified invocation (including body support)
my site's theme
I notice sh_load.js adds styles dynamically by creating a "style" element. There is an existing patch #2860612 which sort of does the same thing, but creates a "link" element dynamically.
Question: is there an advantage to creating a "style" element instead of a "link" element?
This line doesn't make much sense:
document.body.addEventListener("load", sh_go(), true);
Here you are calling sh_go instead of adding it as an event handler. I think this is causing the exception to be thrown in Firefox.
Hm. You're right. However, when I try to add it as a function reference, it never fires. Not quite sure about why that is... maybe it's actually loaded /after/ the body? I know I'm close here...
As to creating a style tag rather than a link, it is my recollection (perhaps erroneous) that some browser or other had difficulty adding link tags after loading (or perhaps it was from within the body) whereas adding a style tag goes without issues.
@gnombat: since a style element is "closer" to the document than a link, it has higher precedence of the external file in terms of the regular "cascade".
The css in the link however can be cached by the browser, but also adds another server request. If the style element also has an ID attribute, say some language tag the styles apply to such as id="php-sh" or id="perl-sh", one may change its contents (via JS of course) on-the-fly. Not sure of there'd be use-case for this regarding SHJS, but that's what tools such as jQuery UI do for speedy eye-candy updates.
So neither "solution" has an advantage over the other - me thinks - and utility (as usualy) depends on the website's needs :-)