rowid,title,contents,year,author,author_slug,published,url,topic
135,A Scripting Carol,"We all know the stories of the Ghost of Scripting Past – a time when the web was young and littered with nefarious scripting, designed to bestow ultimate control upon the developer, to pollute markup with event handler after event handler, and to entrench advertising in the minds of all that gazed upon her.

And so it came to be that JavaScript became a dirty word, thrown out of solutions by many a Scrooge without regard to the enhancements that JavaScript could bring to any web page. JavaScript, as it was, was dead as a door-nail.

With the arrival of our core philosophy that all standardistas hold to be true: “separate your concerns – content, presentation and behaviour,” we are in a new era of responsible development the Web Standards Way™. Or are we? Have we learned from the Ghosts of Scripting Past? Or are we now faced with new problems that come with new ways of implementing our solutions?

The Ghost of Scripting Past

If the Ghost of Scripting Past were with us it would probably say: 


	You must remember your roots and where you came from, and realize the misguided nature of your early attempts for control. That person you see down there, is real and they are the reason you exist in the first place… without them, you are nothing.


In many ways we’ve moved beyond the era of control and we do take into account the user, or at least much more so than we used to. Sadly – there is one advantage that old school inline event handlers had where we assigned and reassigned CSS style property values on the fly – we knew that if JavaScript wasn’t supported, the styles wouldn’t be added because we ended up doing them at the same time.

If anything, we need to have learned from the past that just because it works for us doesn’t mean it is going to work for anyone else – we need to test more scenarios than ever to observe the multitude of browsing arrangements we’ll observe: CSS on with JavaScript off, CSS off/overridden with JavaScript on, both on, both off/not supported. It is a situation that is ripe for conflict.

This may shock some of you, but there was a time when testing was actually easier: back in the day when Netscape 4 was king. Yes, that’s right. I actually kind of enjoyed Netscape 4 (hear me out, please). With NS4’s CSS implementation known as JavaScript Style Sheets, you knew that if JavaScript was off the styles were off too.

The Ghost of Scripting Present

With current best practice – we keep our CSS and JavaScript separate from each other. So what happens when some of our fancy, unobtrusive DOM Scripting doesn’t play nicely with our wonderfully defined style rules?

Lets look at one example of a collapsing and expanding menu to illustrate where we are now:

Simple Collapsing/Expanding Menu Example

We’re using some simple JavaScript (I’m using jquery in this case) to toggle between a CSS state for expanded and not expanded:

JavaScript

$(document).ready(function(){
	TWOFOURWAYS.enableTree();
});
var TWOFOURWAYS = new Object();
TWOFOURWAYS.enableTree = function ()
{
	$(""ul li a"").toggle(function(){
		$(this.parentNode).addClass(""expanded"");
	}, function() {
		$(this.parentNode).removeClass(""expanded"");
	});
	return false;	
}

CSS

ul li ul {
	display: none;
}
ul li.expanded ul {
	display: block;
}

At this point we’ve separated our presentation from our content and behaviour, and all is well, right?

Not quite.

Here’s where I typically see failures in the assessment work that I do on web sites and applications (Yes, call me Scrooge – I don’t care!). We know our page needs to work with or without scripting, and we know it needs to work with or without CSS. All too often the testing scenarios don’t take into account combinations.

Testing it out

So what happens when we test this? Make sure you test with:


	CSS off
	JavaScript off


Use the simple example again.

With CSS off, we revert to a simple nested list of links and all functionality is maintained. With JavaScript off, however, we run into a problem – we have now removed the ability to expand the menu using the JavaScript triggered CSS change.

Hopefully you see the problem – we have a JavaScript and CSS dependency that is critical to the functionality of the page. Unobtrusive scripting and binary on/off tests aren’t enough. We need more.

This Ghost of Scripting Present sighting is seen all too often.

Lets examine the JavaScript off scenario a bit further – if we require JavaScript to expand/show the branch of the tree we should use JavaScript to hide them in the first place. That way we guarantee functionality in all scenarios, and have achieved our baseline level of interoperability. 

To revise this then, we’ll start with the sub items expanded, use JavaScript to collapse them, and then use the same JavaScript to expand them.

HTML

<ul>
	<li><a href=""#"">Main Item</a>
		<ul class=""collapseme"">
			<li><a href=""#"">Sub item 1</a></li>
			<li><a href=""#"">Sub item 2</a></li>
			<li><a href=""#"">Sub item 3</a></li>
		</ul>
	</li>
</ul>

CSS

/* initial style is expanded */
ul li ul.collapseme {
	display: block;
}

JavaScript

// remove the class collapseme after the page loads
$(""ul ul.collapseme"").removeClass(""collapseme"");

And there you have it – a revised example with better interoperability.

This isn’t rocket surgery by any means. It is a simple solution to a ghostly problem that is too easily overlooked (and often is).

The Ghost of Scripting Future

Well, I’m not so sure about this one, but I’m guessing that in a few years’ time, we’ll all have seen a few more apparitions and have a few more tales to tell. And hopefully we’ll be able to share them on 24 ways.

Thanks to Drew for the invitation to contribute and thanks to everyone else out there for making this a great (and haunting) year on the web!",2006,Derek Featherstone,derekfeatherstone,2006-12-21T00:00:00+00:00,https://24ways.org/2006/a-scripting-carol/,code