Even so, I’ll think I’ll stick to the method I’ve been using as I:
a) don’t agree with having javascript in the html document (and most definitely not within the body) – this should be in a seperate file.
b) find it useful (and far less confusing) to work with two seperate css files: one which contains the “normal” state of a page, one which adds/overwrites the normal state for those users which have js available.

The technique I use is a variation on the first method. It *does* use document.write, but from within the js file.
I don’t mind it being “tied to a specific place in the document” as that place is and should always be the same anyway: the js file should load from the head after the css file has been loaded.

For those interested: I’ve described this method in more detail as part of an accessible fold-out menu tutorial here:
http://adviesenzo.nl/examples/cssjsmenu/

Some browsers do not automatically have the document.documentElement object. I’ve corrected this in my library with this line of code:

if (!document.documentElement) document.documentElement = document.getElementsByTagName(‘html’)[0];

Sorry I didn’t include that — I thought it was for an ancient browser and not something still in use like IE. Guess I gotta comment my code…

I can’t help you with the local/online issue, but if you’re doing serious development you might want to explore running a webserver on your local machine. You can find easy installers for “WAMP” server configs just through a google search.

I’ve been struggling to prevent accessible hidden content from flashing up on page load.
Tried the domready technique but wasn’t impressed with the results.
Even tried placing hidden content in tags then redefining via the DOM. Unfortunately Firefox has a bug.

I prefer Ben’s method purely for removing script from the body but I cannot get it to work with IE.
Any workarounds Ben or just use Ara’s?

1. DTDs are created to validate the document as it is delivered, and not the interpreted or modified document held in memory by the client app. Thus, class attributes added to the html tag are invalid, but className values added to the html element via js are perfectly valid.

2. CSS selectors do not check themselves against the html DTD, and any element can have any class, so long as both the class and element name follow the proper naming convention (e.g., not starting with a number, no spaces, etc.).

So, it is valid to add className values to the html element, and to target your CSS selectors to it.

The pattern that I use is this:
a) when the JS executes, add one permanent and one temporary className:
document.documentElement.className += ‘ domCapable domLoading’;

b) after the DOM has been loaded (via a similar technique to the JQuery “ready”), replace the temp className with one that recognizes the new state:
document.documentElement.className += ‘ domReady’;
document.documentElement.className = document.documentElement.className.replace(/\bdomLoading\b/,”).replace(/\s+/,’ ‘);

Most of my “hide until JS runs” CSS then goes like this, where the “off” state is triggered by the html class and the “on” state is both the default and triggered by a class interactively added by JS:

html.domCapable #foo ul { display:none; }
#foo ul,
div#foo ul.show { display:block; }

(Notice the extra specificity of the added “div” in the “on” state to match the “off” state specificity — you could also just remove the “html” from the “off” state selector.)