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
335,Naughty or Nice? CSS Background Images,"Web Standards based development involves many things – using semantically sound HTML to provide structure to our documents or web applications, using CSS for presentation and layout, using JavaScript responsibly, and of course, ensuring that all that we do is accessible and interoperable to as many people and user agents as we can.

This we understand to be good. 

And it is good. 

Except when we don’t clearly think through the full implications of using those techniques.

Which often happens when time is short and we need to get things done.

Here are some naughty examples of CSS background images with their nicer, more accessible counterparts.

Transaction related messages

I’m as guilty of this as others (or, perhaps, I’m the only one that has done this, in which case this can serve as my holiday season confessional)  We use lovely little icons to show status messages for a transaction to indicate if the action was successful, or was there a warning or error? For example:

“Your postal/zip code was not in the correct format.”

Notice that we place a nice little icon there, and use background colours and borders to convey a specific message: there was a problem that needs to be fixed. Notice that all of this visual information is now contained in the CSS rules for that div:

<div class=""error"">
     <p>Your postal/zip code was not in the correct format.</p>
 </div>

 div.error {
     background: #ffcccc url(../images/error_small.png) no-repeat 5px 4px;
     color: #900;
     border-top: 1px solid #c00;
     border-bottom: 1px solid #c00;
     padding: 0.25em 0.5em 0.25em 2.5em;
     font-weight: bold;
 }

Using this approach also makes it very easy to create a div.success and div.warning CSS rules meaning we have less to change in our HTML.

Nice, right?

No. Naughty. 

Visual design communicates

The CSS is being used to convey very specific information. The choice of icon, the choice of background colour and borders tell us visually that there is something wrong. 

With the icon as a background image – there is no way to specify any alt text for the icon, and significant meaning is lost. A screen reader user, for example, misses the fact that it is an “error.” 

The solution? Ask yourself: what is the bare minimum needed to indicate there was an error? Currently in the absence of CSS there will be no icon – which (I’m hoping you agree) is critical to communicating there was an error.

The icon should be considered content and not simply presentational.

The borders and background colour are certainly much less critical – they belong in the CSS.

Lets change the code to place the image directly in the HTML and using appropriate alt text to better communicate the meaning of the icon to all users:

<div class=""bettererror"">
     <img src=""images/error_small.png"" alt=""Error"" />
     <p>Your postal/zip code was not in the correct format.</p>
 </div>

 div.bettererror {
     background-color: #ffcccc;
     color: #900;
     border-top: 1px solid #c00;
     border-bottom: 1px solid #c00;
     padding: 0.25em 0.5em 0.25em 2.5em;
     font-weight: bold;
     position: relative;
     min-height: 1.25em;
 }

 div.bettererror img {
     display: block;
     position: absolute;
     left: 0.25em;
     top: 0.25em;
     padding: 0;
     margin: 0;
 }

 div.bettererror p {
     position: absolute;
     left: 2.5em;
     padding: 0;
     margin: 0;
 }

Compare these two examples of transactional messages

Status of a Record

This example is pretty straightforward. Consider the following: a real estate listing on a web site. There are three “states” for a listing: new, normal, and sold. Here’s how they look:

Example of a New Listing

Example of A Sold Listing

If we (forgive the pun) blindly apply the “use a CSS background image” technique we clearly run into problems with the new and sold images – they actually contain content with no way to specify an alternative when placed in the CSS.

In this case of the “new” image, we can use the same strategy as we used in the first example (the transaction result). The “new” image should be considered content and is placed in the HTML as part of the <h2>...</h2> that identifies the listing.

However when considering the “sold” listing, there are less changes to be made to keep the same look by leaving the “SOLD” image as a background image and providing the equivalent information elsewhere in the listing – namely, right in the heading.

For those that can’t see the background image, the status is communicated clearly and right away. A screen reader user that is navigating by heading or viewing a listing will know right away that a particular property is sold.

Of note here is that in both cases (new and sold) placing the status near the beginning of the record helps with a zoom layout as well.

Better Example of A Sold Listing

Summary

Remember: in the holiday season, its what you give that counts!! Using CSS background images is easy and saves time for you but think of the children. And everyone else for that matter… 

CSS background images should only be used for presentational images, not for those that contain content (unless that content is already represented and readily available elsewhere).",2005,Derek Featherstone,derekfeatherstone,2005-12-20T00:00:00+00:00,https://24ways.org/2005/naughty-or-nice-css-background-images/,code