Thanks for sharing!
Ole was mentioning this above as well, but to my knowledge, it’s not valid to add properties to the HTML element itself.

Nice article, here’s one more varient to add to the mix:
<script type="text/javascript">/*<![CDATA[*/
document.documentElement.className="hasJS";
/*]]>*/</script>

Placed straight after the title element, it adds the class .hasJS to the HTML element (valid grammatically but cannot have properties).
So does not interfere with body element at all.

I sometimes add an extra variable which is set server-side:
var ajaxOn=true;
Which may be switched via a content link for accessibility.

Example: webSemantics

It’s a good point about screen readers. Unfortunately I don’t have access to proper screen reader testing opportunities at the moment either, but I had a friend do brief tests for me.

The result can, most likely, vary from screen reader to screen reader, but a recommended alternative CSS approach to avoid having content not being read is using:

position: absolute;
left: -999px;

instead of

display: none;

Then, have your script change the value to:

position: static;
left: 0;

when showing the element.

Just heard about this technique on Boagworld and came to investigate. I’ve looked through the comments and search for any mention of screen readers and didn’t find anything. Why is this important?

My understanding about why people opt for the ‘display content by default, hide afterwards with JavaScript ‘ technique is not *just* about providing something for non-JS capable users, but also for people with assistive tech.

If the page loads and has content hidden with CSS, the screen reader (to use the typical example of assistive technique) does not get to ’see’ all the content and therefore cannot then be relayed to the user; using the ’show by default then hide it on page load’ technique gets around that problem - the assistive tech gets to ’see’ the whole page and can relay that information accordingly, even if it is subsequently hidden on screen.

Now, I can see what you’ve done here - you’re using JavaScript at what seems like a good point in the page load process to load the additional hide styles to avoid the flash, but I suspect that this will then make any of that content invisible to assistive tech users. I say *suspect* as I’m not able to test that theory out as I type this (at work, no screen reader available on this machine).

Could you look into that aspect of the technique? If it does present accessibility issues, then a note of warning should be applied.

Thanks

Yes, it’s always good to have an option.

Greetings, Stefan

Yep, always use the right tool for the job.

I haven’t tried but I just realized that it will only work for Effects … P6Y’s Element.hide/show doesn’t use callbacks.

But then again why use P6Y for such simple operations.

Well, you know what they say about assumptions, right?
But yes, if that’s the case, you need to set the className or something similar before calling the actual effect then.

No, the way it works is that it will read in the extra CSS file, through JavaScript, before the body has even started loading.