Actionscript, JavaScript, and SCORM

Update: A few months after writing this journal entry, I developed SCORM class files for ActionScript 2 and ActionScript 3 (both require ExternalInterface). Check them out here.

For the last week, I’ve been doggedly attempting to create a hybrid of Flash-to-JavaScript communication techniques for creating cross-browser SCORM-conformant courses that work with almost any version of Flash Player. Today I threw in the towel. Here’s my story.

Some background on SCORM in regards to JavaScript and ActionScript

  • SCORM is a standardized method of communicating between a web-based course and a Learning Management System (LMS).
  • SCORM communication is most commonly handled by JavaScript.
  • A Flash-based course therefore needs to communicate with the JavaScript in an HTML file in order to send SCORM calls to the LMS.

It looks like this:

course communication: AS to JS to LMS

Unfortunately, even though they’re both part of the ECMAScript family, ActionScript and JavaScript cannot natively communicate; a ‘communication system’ has to be installed in each Flash-JavaScript project if you want them to talk. Think of it as needing a cell phone to call your mom because she lives in another part of the country!

[ you > cellphone < mom ]

[ actionscript > communication system < javascript ]

Flash-JavaScript Communication: Old-School Versus New-School

Flash-to-JavaScript communication has long been a heavily-discussed topic. Let me try and get you up to speed on it without getting too technical. Old-School refers to Flash Players v6-7, while New-School refers to Flash Players v8+.

Old-School #1: FSCommand

The first old-school technique is to use FSCommand. FSCommand allows synchronous communication, and is pretty straightforward to implement. It’s arguably the most widely-used old-school method for Flash-JavaScript communication in Flash-based SCORM-conformant online courses. (Wow, that’s a lot of hyphens!) But FSCommand has a huge downside: it isn’t cross-platform. It’s specific to Windows machines, and will fail on Macs and Linux boxes.

Old-School #2: GetURL and SetVariable

The second old-school technique is to use ActionScript’s getURL() coupled with SetVariable in JavaScript. For a while, this technique seemed to be popular with a segment of Flash-based course developers who worked with SCORM. The technique basically works like this:

getURL in ActionScript invokes a function contained in the JavaScript. The JavaScript function contains a reference to the SWF, and invokes a method (function) called ‘SetVariable’ in the SWF.

Example:


//ActionScript
getURL("javascript:'myFunction(\'myVariable\')'");

//JavaScript
var myVar2 = "Send me to Flash!";

function myFunction(v){
   var swf = window.document.mySwfId;
   swf.SetVariable("myVariable", myVar2);
}

//ActionScript:
//watch() or setInterval() used here to detect
//when variable "myVar" has been updated.

This technique wasn’t very popular because it was hard to implement, could only pass strings (no object, arrays, etc.), and was also asynchronous.

Being asynchronous was probably the biggest sticking point for most people, because it meant you couldn’t return the data from JavaScript into ActionScript right away — no var myVariable = getURL("javascript:'myFunction(\'myVariable\')'");; you had to send your request from ActionScript to JS, then wait for it to come back. This required some ugly tricks such as object.watch and setInterval to check if the variable had been updated before you could use it in Flash.

Old-School #3: The Flash-JavaScript Integration Kit

The third old-school technique is to use a proxy SWF and LocalConnection. I believe this was first discussed by the guys at MustardLab, and was turned into a full-blown system — the Flash-JavaScript Integration Kit (FJIK) — by two Macromedia employees. I’ll try and explain this as simply as I can.

First, a few things to note about loading external variables into a SWF:

  1. When a Flash SWF first loads on a page, it’s really easy to pass variables into the SWF from your HTML page using FlashVars.
  2. If an HTML page has two SWFs embedded on it, passing variables between the two SWFs is (relatively) easy using LocalConnection.
  3. Passing variables to a SWF AFTER the SWF has already been embedded to the page is the tricky part.

(Warning: this may be a gross oversimplification to some die-hard coders.)

The main idea behind the FJIK method is to dynamically embed a second SWF to your HTML page whenever you want your original SWF to load a variable from JavaScript. This second SWF is usually referred to as a proxy or gateway SWF. The data is loaded into the second SWF using FlashVars as it gets embedded in the HTML. The data is then transferred from the second SWF to the first SWF using LocalConnection. When the transfer is complete, the second SWF can be deleted.

Sounds reasonable, right? This biggest benefit of the FJIK method is that it isn’t limited to passing strings; it supports passing different variable types, such as objects and arrays. It proved to be a popular technique, but it had a few significant drawbacks: transfer speed (you have to wait for a new SWF and FlashVars to load each time you make a call), the required use of 4 or 5 external files (.as, .js, and .swf) is cumbersome, and — like the getURL method — the data is returned asynchronously. No instant ‘return’ statements.

New-School: ExternalInterface

The new-school technique is to use ExternalInterface, which was specifically designed by Macromedia Adobe to make Flash-JavaScript communication much easier. By most accounts, they did an excellent job — data can now be called from ActionScript and returned from JavaScript synchronously, which means your ActionScript and JavaScript can work as one. The code has some kinks, but generally speaking has worked pretty well.

Back to the point: Why the attempt at a hybrid?

You might ask: Why was I trying to make a hybrid of old and new techniques in the first place? The new-school ExternalInterface method works fine and is super-easy!

Answer: ExternalInterface works fine for people with Flash Player 8 and above. That eliminates the majority of the student population I’m targeting. Yes, I know Flash Players v8-9 are supposed to be ubiquitous, but the IT dept. at my workplace installed Flash Player 7 in early 2005 and hasn’t updated most of the machines since then. Employees have no admin rights on their computers, and therefore way to update Flash without calling IT to come do it. When you have over 5,000 employees, this becomes a big issue. It will be at least a few months before the majority of users get Flash Player upgrades.

I also have a colleague in a similar situation, except his target audience is mostly Mac users! This means FSCommand won’t work for him, and can’t hold him over until his end users get Flash Player upgrades.

Simply put, I was hoping to devise a solution for both our problems: a Flash-JavaScript communication method that doesn’t care what version of Flash you have or what platform you’re using! What a dream, huh?

How I hoped it would work

I wanted to create an abstraction layer that separates the SCORM calls from any particular Flash-JavaScript communication method. I was hoping I could do something as simple as this:


//ActionScript

var canDoEI:Boolean = ExternalInterface.available;
getURL("javascript:setCanDoEI(" +canDoEI +")");

function getDataFromJS(v){
   if(canDoEI){
      //external interface call
   } else {
      //old-school method
   }
}

//JavaScript

var canDoEI = false;

function setCanDoEI(v){
   canDoEI = v;
}

function sendDataToFlash(v){
   if(canDoEI){
      //external interface call
   } else {
      //SetVariable method
   }
}

This would have allowed me to use the same function calls in Flash Player v6-7 as in Flash Player v8-9, regardless of what technique was being implemented under-the-hood. However, because ExternalInterface and the FJIK each rely on imported classes, have such different syntax, and aren’t both synchronous (only ExternalInterface is synchronous), it would have been a huge headache to try and cram these very different techniques into one course. Bah humbug.

Why not use getURL/SetVariable instead of FJIK?

Granted, the getURL/SetVariable method is much easier to implement than the FJIK method, but it’s also limited to passing strings, and is asynchronous. The asynchronous nature of the getURL/SetVariable method is the main sticking point for me… it’s really tricky to set up the watchers/intervals needed to detect when the variable has successfully been returned from JavaScript. It doesn’t mix well with the synchronous and much speedier ExternalInterface.

So whatcha gonna do?

Wait until we upgrade to Flash Player 9. Sucks, but it’s a pragmatic choice.

I’m in a unique situation in that our IT dept. only supports Internet Explorer on Windows PCs. So far I’ve been able to use the easy-to-implement (and PC-only) FSCommand. I’ll be the first to admit this is something I’ve never been happy about, but hey, it has been a practical and fully-functioning solution for over 2 years. When I developed my current Flash course interface, I knew ExternalInterface was over the horizon, so I didn’t bother with getURL or the FJIK (which hadn’t been released yet). Little did I know that over 2 years later we’d still be supporting Flash Player 7!

In my own defense, I must say that I haven’t ignored standards and best-practices: everything else I’ve built is been cross-browser and cross-platform, including course content. But my guilt is catching up to me, along with a new crop of Mac users at work! It’s in all of our best interests for me to stop using FSCommand in our SCORM courses. If it weren’t for that stinkin’ Flash Player 7 on our older computers… grrr.

So my plan for now is to develop an ExternalInterface version of our Flash-based course interface, and have it ready for that fateful day when the IT guys tell me Flash Player 9 is up and running on (most of) our machines. Sigh… I was hoping for a happier ending!

Related links

Here are some interesting articles I encountered while doing my research:

Advertisements

A cross-browser JavaScript prompt

You might be looking at the title of this entry and say “Well, DUH! JavaScript’s prompt() is already cross-browser!”

While working on a project earlier today, I discovered a nasty little problem… Internet Explorer v7 (IE7) disables prompt() by default! This means you can’t rely on prompt() being available in IE7 when building your online applications.

In most cases, prompt() should be avoided altogether. Maybe Microsoft was right in disabling prompt(), since so many malicious sites take advantage of it. However, I had a legitimate use for it today, and was very irked to find out it won’t work in IE7. (I develop in Firefox and IE6, which might explain to some of you why I’m late to the party with discovering this limitation in IE7.)

After googling for a while — yes, I use google as a verb — it appears quite a few people have developed workarounds for the prompt() limitation in IE7. Most of them were bulky or required a bit too much hacking for my tastes. There were a few nice examples [link no longer available] out there, but in the end, I decided to make my own workaround using Microsoft’s proprietary showModalDialog function.

Microsoft’s showModalDialog allows the developer to load an external HTML file into a generated window and give it focus. The user can’t click back to the original document until they’ve closed the modal window, just like a prompt(), alert(), or confirm(). The generated window behaves much like a pop-up window (it can be sized, show/hide scrollbars, etc.), but to my knowledge, modal windows aren’t blocked by pop-up blockers.

I’ll admit that using an external HTML page feels like a big disadvantage compared to a simple prompt(). However, one potential advantage showModalWindow provides is the ability to style the faux prompt window; in IE, the prompt window has always looked and behaved a little different from any of the other dialog windows (alert, confirm). Now we can have it visually fit in with the rest of the family! Due to this styling issue, and to make my life easier, I decided to use showModalWindow on all versions of IE, not just IE7.

Native IE6 prompt:
Native IE6 prompt

Native Firefox 2 prompt:
Native Firefox 2 prompt

New faux prompt, as seen in IE6:
Faux prompt, IE6

New faux prompt, as seen in IE7 (WinXP):
New faux prompt, as seen in IE7 (WinXP)

Important note: The IE7 modal window will forcibly display the address and status bars if being called by a server (not localhost) which isn’t listed in that user’s list of ‘Trusted Sites.’ This is annoying, but still better than having no prompt() at all. IE6 forcibly displays the status bar, but not the address bar.

Example

Before I dig into the code, here’s a functioning example. There are two files involved in this hack: the main HTML page calling the prompt, and the faux prompt HTML page.

The traditional prompt()

For those of you new to using prompts, here’s an example of a traditional prompt in action:


window.onload = function (){
   var name = prompt("Please enter your name", "");
   if(name){
      alert("You entered '" +name +"'.");
   }
}

Return values

A key feature of prompt() is that it returns the value of the textfield as a string. If nothing was typed into the text field, prompt() returns either null or false, depending on your browser. If the user clicks ‘cancel’, prompt() returns false.

Our faux prompt for IE needs to work the same way. As luck would have it, showModalWindow allows us to specify return values.

Prompt text

Another key feature of prompt() is the ability to display your own text in the prompt, such as “Please enter your name.” To make our lives easier, our faux prompt should work the same way, using the same syntax.

Our IE-specific function: iePrompt()

In all its glory:


function iePrompt(str){
   var settings = "dialogWidth: 290px; dialogHeight: 160px; center: yes; edge: raised; scroll: no; status: no;";
   return window.showModalDialog("iePrompt.html", str, settings);
}

Let’s break it down.


function iePrompt(str){

Since we can’t use the traditional prompt(), we need to create a new, similar function. Just as prompt allows you to specify what text will display by passing a string,

prompt("This text will display in my prompt","")

we want to be able to pass a string in our new function:

iePrompt("This text will display in my prompt")


var settings = "dialogWidth: 290px; dialogHeight: 160px; center: yes; edge: raised; scroll: no; status: no;";

IE’s showModalDialog allows you to style the window much like a pop-up window. The settings are entered as a single string. For convenience and readability, I placed all the settings in a variable named “settings”. You can tweak these settings to suit your own needs. A list of optional parameters can be found here.

Important note: The height of the modal window is set here using dialogHeight; if the display text (in this case “Please enter your name”) wraps to the next line, the window will NOT expand to fit it. If you’re working with long strings, you’ll need to test the height of your modal window, or develop your own sizing routine. Also note that in IE6, dialogHeight referred to the height of the entire dialog window. In IE7, the model was changed, and dialogHeight now refers ONLY to the height of the content. See this IEBlog for more info.

return window.showModalDialog("iePrompt.html", str, settings);

As mentioned earlier, showModalWindow can return a value the same way prompt() returns a value. We want our iePrompt() function to pass the value returned by showModalWindow.

  • iePrompt.html is the name/path of the HTML file containing a form that mimics prompt().
  • str is the text that will be displayed in the prompt.
  • settings is the variable containing the settings string we defined earlier.

The iePrompt.html file

I don’t want to spend too much time explaining the HTML file, as it’s a simple HTML file containing a wee bit of CSS for styling, and a very tiny form. There are some important elements to note, though.

The submit function


function formSubmit(){
   var str = document.getElementById("promptText").value;
   if(str){  
      window.returnValue = str;
   } else {  
      window.returnValue = false;
   }
   window.close();
}

In order to get the showModalDialog function to return a value, we have to make our form return a value. To do this, we have to specifically use window.returnValue. The code is set up to conditionally send either the content of the promptText field, or the value false, just like a normal prompt.

After returning the value to the page that called the prompt, we need to close the modal window by calling window.close.


function formCancel(){
   window.returnValue = false;
   window.close();
}

Prompts also have cancel buttons. We want our modal window to have a cancel button that behaves just like a prompt. To do this, we set up a function that returns the value false and closes the modal window.


window.onload = function (){
   var str = window.dialogArguments;
   if(str){
      document.getElementsByTagName("label")[0].innerHTML = str;
   }
}

This bit of code grabs the display text value being passed by iePrompt and dynamically inserts it into a label on our form. We’re passing the argument using the dialogArguments property of the modal window generated by showModalDialog.


<body onbeforeunload="formCancel();">

Lastly, we need to take into account the fact that many people choose to click the dialog window’s close button (X) instead of OK or Cancel. Using onbeforeunload allows us to call formCancel() if the user decides to close the window.

And that’s it! We now have a functioning prompt for IE.

Putting it into action

Now that we have our custom IE prompt, we need to integrate it with non-IE browsers. Fortunately, this is a pretty simple task.

Determining if the browser is IE

Rather than use some elaborate browser-sniffing technique, we’ll stick to supported feature detection, which is considered a best-practice by the DOM scripting crowd. This is easily accomplished by checking for window.showModalDialog. If the return value is true, the browser is a flavor of Internet Explorer (v4 and higher), and supports our new prompt method. If the return value is false, the browser isn’t IE and should be able to use a traditional prompt().


function cbPrompt(str){
   try {
      if(window.showModalDialog){ return iePrompt(str); }
         else { return prompt(str, ""); }
   } catch (e) { 
         return false; 
   } 	
}

I decided to use a try/catch statement for future expandability (being able to add extra functionality, such as using confirm() to validate the text entered by the user. You could rewrite it to use simple if/else statements.

I wrapped the logic into a new function called cbPrompt (“cb” meaning cross-browser). Now anytime I need a prompt, I simply call cbPrompt instead of prompt():


window.onload = function (){
   var name = cbPrompt("Please enter your name");
   if(name){
      alert("You entered '" +name +"'.");
   }
}

As you can see, it’s almost exactly the same as using the traditional prompt:


window.onload = function (){
   var name = prompt("Please enter your name", "");
   if(name){
      alert("You entered '" +name +"'.");
   }
}

Just remember that you have to ensure the iePrompt.html file is present and that the path defined in the iePrompt function is accurate.

Here’s a fully-functional cross-browser example.

New: SWFObject examples page

I’ve been creating assorted SWFObject examples for a few months now, usually in response to a forum post at the SWFObject forum. These examples have been piecemeal, just kinda floating out there with no clear links to them or documentation explaining what they are. I decided to create a guide for the examples, which gives a little bit of background for each example as well as the URL for each example.

http://www.pipwerks.com/lab/swfobject/

Captivate-JavaScript limitations

Captivate SWFs can communicate with the host HTML file via JavaScript, but the scripting options suffer from severe limitations imposed by the Captivate authoring environment.

For starters, this communication is (generally) a one-way street: the JavaScript goes out of Captivate to the HTML file, but the JavaScript in the HTML can’t really ‘talk’ to the Captivate SWF.

Here’s a simple example of a Captivate SWF calling a function located in the HTML host. Once the JavaScript in the HTML file receives the function call, it executes it. In this case, the function identify() will manipulate DOM elements to display a message. [ Download the source files. ]

The ability to send JavaScript calls from Captivate SWFs should open up a number of possibilities, even if we’re limited to one-way calls. A few ideas off the top of my head:

  • Use JavaScript to track a user’s choices or actions while interacting with a scenario-based (branching) Captivate SWF.
  • Use JavaScript to control the SWF’s navigation.
  • Use JavaScript to relay SWF data (such as current slide number, clicked items, etc.) to the HTML container for an AJAX-like user experience.

However, Captivate’s JavaScript capabilities suffer from three severe limitations:

  1. The aforementioned one-way-street issue
  2. Only static hard-coded calls can be made
  3. JavaScript can only be executed in limited circumstances, and at the expense of other Captivate functionality

The first item is pretty obvious, so I won’t go into it here.

The second item is absolutely painful. Captivate’s JavaScript capabilities are limited to static hard-coded calls; Captivate doesn’t allow dynamic JavaScript variables, such as a dynamic call based on the slide number. This eliminates the ability to use easy-to-maintain dynamic code, which means you’d have to spend hours hand-coding every little JavaScript call in the SWF. This can get very complex very quickly, and is a royal pain in the buttocks.

Matter-of-fact, Captivate makes it hard to do ANY kind of dynamic scripting, whether it’s JavaScript or Actionscript; Actionscript is the native language for Captivate SWFs, but is strangely — and strictly — off-limits to Captivate users.

(I don’t know what the folks at Macromedia/Adobe were thinking when they implemented such poor scripting functionality into Captivate… they have a proud history of making their applications scriptable — Authorware, Director, and Flash were all astounding successes — but they really dropped the ball with Captivate.)

The third item is when/where JavaScript can be executed from Captivate. Captivate’s developers took an odd approach and decided that JavaScript can be executed:

  • When something is clicked
  • At the end of a slide
  • At the end of the movie

To complicate things further, only ONE action can be taken per event. This means you can either choose to execute JavaScript, OR you can jump to another slide OR you can send e-mail, etc. If you want to execute a single line of JavaScript, you will be forced to give up any navigation option other than allowing the movie to progress to the next slide (playing the SWF linearly).

This eliminates the ability to use JavaScript when working with branching or other non-linear navigation in Captivate, unless you implement crazy workarounds, such as building empty slides that execute JavaScript a split second before transitioning to the intended slide.

Summary

When I started this journal entry, I had no intention of writing a rant. However, while trying to come up with useful examples of Captivate-JavaScript functionality, I was reminded just how ugly Captivate’s JavaScript support is. C’mon Adobe… you’ve created Actionscript 3.0, Flex, Flash, Acrobat, Acrobat Connect, Apollo, the Spry framework, and more… why can’t you give us a little more control over JavaScript and/or Actionscript in Captivate? It’s peanuts in comparison to your other projects!

Email address obfuscation

Note: This post contains old code. Read about the updated code at http://pipwerks.com/2009/02/01/obfuscating-email-addresses-revisited/

Everyone knows the story: an innocent email address is posted online and a big bad spambot finds it, relaying it to every spammer on the face of the earth… the email address becomes useless due to the 500 spam emails you get every day!

I always try to encode email addresses on sites I build in an effort to make the addresses more difficult to abuse. This has become a very common practice, thanks largely to free encoder tools such as the Hivelogic Enkoder by Dan Benjamin.

Some encoding methods are easy to beat

However, precisely because of their popularity, some spambots are being written to overcome simpler encoding methods, such as obscuring the address using character entities. A block of text encoded as character entities is easy to defeat with automated decoders, even by an amateur like me. The patterns are still there: the ‘mailto’ protocol, the @ sign, the .com/.org/.whatever, etc… they just look like this:


&#121;&#111;&#117;&#114;&#110;&#097;&#109;&#101;
&#064;&#115;&#111;&#109;&#101;&#100;&#111;&#109;
&#097;&#105;&#110;&#046;&#099;&#111;&#109;

Javascript shouldn’t be required

More complex encoding methods, such as the aforementioned Hiveware enkoder, still seem to work well, but they also rely on Javascript. While the Javascript adds several layers of complexity for the bot to overcome, it also limits what your visitors can do on your site. What if your visitor has Javascript disabled? Many times, they’ll see nothing… no fake email address, no chunks of encoded text, nada. This is a big no-no if you’re a supporter of graceful degradation/progressive enhancement.

I decided to search around for encoding tricks that would work without Javascript. Guess what? I couldn’t find any, aside form the simple character entity encoding described above. It wasn’t much of a surprise, to be honest.

What about spelling it out at myaddress dot com?

I started looking at the common trick of writing “name at somewhere dot com.” I have a couple of problems with this approach: First of all, the address isn’t clickable. Sounds silly, but it’s a big usability component if you’re trying to encourage people to contact you. Secondly, I think it would be easy to write a bot that finds page content written in that format, especially in places where it’s a common practice, such as bulletin boards and forums. This seems like a temptation for a zealous hacker who wants to prove his or her worth. No thanks.

A simple compromise

After kicking around these thoughts for a while, I decided to implement a compromise between two of the three methods I’ve covered so far: using an altered email address to fake out the bots, and using Javascript to make the bots work a little harder.

Granted, I can tell you in advance this isn’t a foolproof method, but it’s very easy to implement and doesn’t leave Javascript-deprived visitors out in the cold.

Part one: Add some useless text to your address.

Yes, that means we’ll be using the standard email link technique:


<a href="mailto:someone@somewhere.com">Email me!</a>

Important! Notice that I didn’t type the email address between the ‘a’ tags… that would make this system pointless! I suggest typing sensible alternate text, such as “Email me!” or the email recipient’s name.

By adding a little bit of unrelated text to the username portion of the address (“REALLYNICE”), we can prevent spambots from knowing what our true email address is:


<a href="mailto:someoneREALLYNICE@somewhere.com">Email me!</a>

So what does this do? It keeps the link clickable, and it prevents the spambot from knowing what our real email address is.

What doesn’t this do? It doesn’t get rid of the useless text (“REALLYNICE”), which means that while the link remains clickable, it’s also useless if the visitor doesn’t manually edit the address.

As the webpage developer, it’s my duty to make the link human-readable, and make the dummy text as obvious as possible. The following example is much easier to read by the average person:


<a href="mailto:someoneRemoveThisText@somewhere.com">Email me!</a>

Part two: use Javascript to make it easier on the end user

At this stage, the email address is somewhat usable, but still requires effort on the end user’s part. If they click the link, it will appear in their email program with the full text “someoneRemoveThisText@somewhere.com”. Some people will see what they have to do and act accordingly, but others might not realize they need to take action.

Here’s where Javascript comes in as a progressive enhancement: we can use Javascript to remove the dummy text when the link is clicked!

A simple Javascript function examines the link text, finds the specified bit of dummy text, and removes it automatically:


function doMail(theLink, key){

    //Get the HREF tag. This includes the anti-spam 'key'
    var before = theLink.getAttribute('href');

    //If the anti-spam key is not found in the link, exit the function without doing anything
    //If the link is clicked more than once, this prevents the Javascript from throwing an error
    if(before.indexOf(key) == -1) return false;

    //Our new variable "addy" is a combination of the text that
    //comes BEFORE the key [0] and AFTER the key [1]
    var addy = before.split(key)[0] + before.split(key)[1];

    //Substitute the original link with the new link ("addy") 
    theLink.href = addy;

}

Sample usage:


<a href="mailto:someoneRemoveThisText@somewhere.com" 
   onclick="doMail(this, 'RemoveThisText')">email</a>

Because the dummy text is specified as a key when the function is called, you can use whatever dummy text you like. For instance, at my office all emails are formatted as: givenname.familyname@ouroffice.org. You could rewrite the address in the following way:


<a href="mailto:givenname.familyname.dummyText@ouroffice.org"
   onclick="doMail(this, '.dummyText')">email</a>

or


<a href="mailto:givennamenoSpam.familyname@ouroffice.org"
   onclick="doMail(this, 'noSpam')">email</a>

Of course, I recommend avoiding terms that are easy for spambots to recognize, such as “nospam”. Why not get creative with something like “SpamSucks”?


<a href="mailto:givennameSpamSucks.familyname@ouroffice.org"
   onclick="doMail(this, 'SpamSucks')">email</a>

You can even put the dummy text in the domain name, if you choose:


<a href="mailto:givenname.familyname@iDontWantSpamAtouroffice.org"
   onclick="doMail(this, 'iDontWantSpamAt')">email</a>

Nothing is invincible!

This email obfuscation method may wind up being easy to crack by the more sophisticated bots, but I feel comfortable knowing that I’ve added a reasonable layer of complexity the spambot must overcome. This in itself will prevent the majority of bots from harvesting my addresses!

I’m also happy because the email address is still human readable (if the dummy text is sensibly written), and is still clickable with or without Javascript. Plus the Javascript is extremely lightweight and the entire method is easier to implement than some of the crazier encoding methods being used today.

Vertical centering — without using tables!

For many years, table-based web page layouts were the rule, not the exception. They were easy to build, they worked cross-browser, and WYSIWYG editors made it a breeze to create and edit tables. CSS-based layouts didn’t really grab hold until just a few years ago, thanks to the evangelism of people like Jeffrey Zeldman and Eric Meyer.

The benefits of CSS-based layouts are very well-documented, and include increased accessibility (for surfers who use assistive technology), ease of site updates (change an entire site’s look and feel with a single stylesheet), and improved search engine rankings (search engines are able to index your content more cleanly when it isn’t surrounded by table markup).

It’s getting easier and easier to avoid table-based layouts these days, and even WYSIWYG editors like Dreamweaver have shifted gears and started including CSS-based layout templates with their software. This is way cool.

But every now and then, a developer like myself will come up against something that was SOOOO easy with table-based layouts and winds up being a royal pain with CSS-based layouts. One of these “d’oh!” moments is when you try to vertically center an element on your web page. Umm… hang on, let me rephrase that: One of these “d’oh!” moments is when you try to vertically center an element on your web page when using Internet Explorer 6.

Firefox supports CSS standards better than Internet Explorer 6 (the dominant browser), and predictably, vertical centering in Firefox is a piece of cake!

This journal entry is devoted to explaining how to get vertical centering working in both Firefox and IE6.

First, an example page.

The ingredients

There are three keys to making this work:

  1. A set of nested DIVs (yes, I know some of you are anti-nested DIV, but hey the world keeps on spinning).
  2. CSS for standards-compliant browsers (Firefox et al)
  3. A separate chunk of CSS for our old friend IE6

Nested DIVs

The first requirement is nested DIVs. You may be thinking “what’s the point of avoiding tables if I still have bloated markup?” My response is that one small set of nested DIVs isn’t nearly as bloated as a table, and using DIVs still helps you keep your markup readable for accessibility purposes and search engines. It’s a good thing! DIVs are also much more flexible should you decide to change your layout later on.

Here’s the layout in all its glory:


<body>
<div id="outer">
  <div id="container">
    <div id="inner">
      <img src="http://pipwerks.com/images/posts/indicator_green.gif" alt="Please wait" width="32" height="32" /><br />
      Loading...<br/>
      Well, not really.<br/>
      But don't I look nice centered like this?
    </div>
  </div>
</div>
</body>

The ‘inner’ DIV is what will hold your content. The ‘outer’ and ‘container’ DIVs’ sole purpose in life is to get your content centered on the page! I’ll explain this in a moment.

The CSS

Let’s look at the CSS:


body {
}

* {
   margin: 0;
   padding: 0;
}

/* macs won't see this! */
html, body { 
   height:100%;
   width:100%;
}
/* END mac */

#outer {
   height:100%;
   width:100%;
   display:table;
   vertical-align:middle;
}

#container {
   display:table-cell;
   vertical-align:middle;
}

#inner {
   text-align: center;
   width: 50%;
   margin-left:auto;
   margin-right:auto;
}

We set all elements on the page to have a default padding and margin of 0. This avoids box-model issues. We also dealt with some Mac inconsistencies with the Mac hack.

As you can see from the CSS, the body and outer elements (outer, container) are set to be 100% wide and 100% tall. The outer element is told to behave like a table (display:table), and is vertically centered using the “vertical-align:middle” property.

By nesting the ‘container’ DIV inside the faux-table, we can make the container DIV behave like a table cell: “display:table-cell”. This DIV is also set to be vertically centered using the “vertical-align:middle” property.

That’s it for the vertical centering in CSS-compliant browsers!

In this case, the ‘inner’ DIV’s CSS is purely for horizontal centering. I set the width to 50% simply because I wanted a narrow DIV, and I centered the DIV horizontally using margin-left: auto and margin-right: auto.

Remember, the code up to this point is for standards-compliant browsers, not IE6.

Dealing with our friend, Internet Explorer 6

Now, you may be thinking that writing different CSS specifically for IE harkens back to the bad old days of browser sniffers and alternate web sites, and you would be correct. However, the alternate CSS is very easy to manage, and doesn’t require a browser sniffer! Thanks to Microsoft’s implementation of conditional comments in IE, we can simply insert a chunk of alternate CSS code into a conditional comment… whatever is inside the comment will be safely ignored by any non-IE browser. Here’s an example:


<!--[if IE ]>
   <style type="text/css">
      body {
         color: #ff0000;
      }
   </style>
<![endif]-->

You can read more about conditional comments at Peter-Paul Koch’s website.

On our vertical centering example, I used the following CSS code in a conditional comment:


#container {
   height: 1px; /* required for IE to properly center vertically */
   position:relative;
   top:50%
}

#inner {
   position:relative;
   top:-50%;
}

Internet Explorer doesn’t support the “display: table”, “display: table-cell” and “vertical-align: middle” properties. To get around this, we have told IE to use relative positioning to move the ‘container’ DIV 50% down from the top of its parent DIV (‘outer’), and to move the ‘inner’ DIV negative 50% from the top its parent DIV (‘container’).

Normally these two values would simply offset each other and cause the ‘inner’ DIV’s content to be displayed at the top of the screen. However, through the magical glitches of IE, by setting the ‘container’ DIV’s height attribute, the DIV suddenly jumps down to the middle of the page, right where we want it to be! I have no idea why, but hey, it works. Here’s the proof.

Important: the height must be set BEFORE the top percentage is declared.

Externalizing the CSS

It’s always a good idea to set up your CSS in external CSS files. This helps keep your web page clean, enables you to re-use your code on other pages, and much more. The CSS contained in the conditional code can also be placed in an external stylesheet. Here’s how I set up my page:


<link href="centering.css" rel="stylesheet" type="text/css" />

<!--[if IE ]>
   <link href="centering-IE.css" rel="stylesheet" type="text/css" />
<![endif]-->

The CSS is exactly the same, but cut and pasted into two external files: centering.css and centering-IE.css.

Now my page is looking clean as a whistle, and I can reuse my code by linking my other pages to my ‘centering’ css files!

Cool, can you do that with a Flash SWF, too?

Yes, you can! Here’s an example.

The code for the Flash example is exactly the same as the first example, except for content: I replaced the contents of the ‘inner’ DIV with some dummy text, and I embedded a Flash SWF using Geoff Stearn’s SWFObject method (the best embedding method I’ve used by far!). No CSS was altered except for the body and font colors.

And there you have it… a nice, (relatively) simple way to vertically center DIVs using CSS and NO tables.

Updates

Thanks to some sharp-eyed readers, here are a few corrections and/or additions:

Update: Here is an example of a Flash SWF embedded with a transparent background. The CSS has been altered slightly: an HTML background image has been specified, and the inner DIV has been set to the exact pixel size of the Flash SWF; this properly centers the SWF and causes scrollbars to appear when a minimum width or height has been reached. Tested successfully in IE6, FF2 and Safari 3 (beta), all Windows XP.

Update 9/03/2007: For IE7, if specifying the height of the inner div, you must also specify the height of the container div in the IE-specific CSS file. For example:

In standard CSS:


#inner {
   text-align: center;
   width: 550px;
   height: 400px;
   margin-left:auto;
   margin-right:auto;
}

In IE7’s CSS:


#container {
   /* required for IE to properly center vertically,
      must match #inner height */
   height: 400px;
   position:relative;
   top:50%
}

Unfortunately, in IE7 this also produces scrollbars (IE7 thinks the page content is larger than it actually is). I plan to do some more research into this when I have the time.

Thoughts on using JavaScript in Adobe Captivate

Having just finished my Making Actionscript calls from Adobe Captivate tutorial, I’ve been looking at Captivate 2.0 a lot the last few days. Specifically, I’ve been looking for ways to use JavaScript in Captivate. I’m a bit disappointed to report that JavaScript can only be used in very limited instances.

From what I can gather, JavaScript calls can be made in the following instances:

  1. At the end of a slide
  2. At the end of the movie
  3. When a clickbox or button is clicked
  4. When a text input field is used

“That sounds like plenty of ways to use JavaScript,” you say? Well, the major shortcoming is this: if you choose to execute JavaScript in any of those cases, you’re giving up the ability to use the other ‘Navigation’ options, such as ‘go to next slide,’ ‘go to previous slide,’ ‘jump to slide,’ ‘open URL or file,’ and ‘open other project.’

Navigation options in Captivate

As you can see in the image above, Captivate only allows you to choose ONE ‘navigation’ option. You can’t execute JavaScript and jump to a slide.

In some cases this may be fine, but what if your Captivate movie is a scenario with branching? A button click or other interaction must occur to tell the movie to jump to the appropriate scenario slide. If you choose to execute JavaScript instead of using a ‘jump to slide’ action, your scenario is toast… you will not be able to navigate to any slide other than the next slide in the timeline.

Johnny doesn’t play well with others

The bottom line is that Captivate is being developed as a stand-alone solution, and is not really meant to integrate with any other course development tools.

A Captivate SWF can be embedded in an HTML-based course interface, but doing so will render the built-in interaction tracking system practically useless. The tracking system is designed to deliver data in a limited, pre-packaged capacity; there is no obvious way to access to the raw tracking data. For instance, if you want to get SCORM calls such as lesson_location from the Captivate SWF, there’s no clear, easy solution for doing so. And there’s no way to set up the Captivate file as a component of a SCORM course… it’s meant to be a be-all-end-all solution (for example it will do ‘LMS initialize’ calls, which is a no-no in the middle of a course).

A Captivate SWF can be loaded into a Flash-based course interface, but because there is no easy access to the Captivate SWF’s Actionscript code, it’s a huge challenge — though not impossible — to extract Actionscript variables from a Captivate SWF. This includes tasks such as controlling the Captivate SWF’s playback using your own Flash playback controls; The sheer number of Captivate ‘help’ sites dedicated to this normally simple exercise is proof enough.

Have you ever tried decompiling a Captivate-generated SWF and inspecting its Actionscript? It’s very enlightening and utterly confusing! (FYI SoThink SWF Decompiler has a limited trial version you can use if you’re curious).

And NO, asking us to export the Captivate movies as FLAs and then customizing in Flash is NOT an appropriate solution. Big chunks of functionality and settings get lost in the conversion, and you can’t send the FLA back to Captivate. It’s a path of no return. The whole point of Captivate was to make things quick and easy and avoid having to do heavy lifting in Flash.

In many ways, Captivate is a great product. It’s the best software I’ve ever used for creating software simulations, and the SWFs it creates are much smaller than video-based tools such as Camtasia.

However, until the Captivate design team starts acknowledging the needs of course developers who use Captivate as a small part of their development toolbox, we will be stuck pulling our hair out and spending hours on end searching for workarounds. And that kinda sucks, don’t you think?

Making Actionscript calls from Adobe Captivate

Diagram of languages spoken by each document

Captivate 2.0 doesn’t include the ability directly manipulate Actionscript. This has been problematic for people like myself who have Flash-based ‘players’ that load and unload both Captivate SWFs and Flash SWFs… we often need the Captivate SWF to perform some kind of action when it reaches its end.

In my case, I usually need the loaded Captivate SWF to tell the Flash container — an e-learning course interface — that a simulation has been successfully completed.

The figure on the right illustrates the problem: Captivate only allows developers to make Javascript calls, even though Captivate SWFs are running Actionscript under-the-hood!

Flash SWFs, on the other hand, traditionally use Actionscript. Granted, there’s a long history of Flash-Javascript tricks, but most of them have been very ‘hacky’ and not very robust.

The HTML container doesn’t recognize Actionscript at all; it only speaks Javascript.

The old solution: embedded SWFs

Diagram of languages spoken by each document (includes embedded SWF)

For a long time, the only reliable workaround had been to import a Flash SWF containing Actionscript into Captivate, and carefully place it on a Captivate slide. It works like this:

  1. Create a blank Flash SWF, then type a small amount of Actionscript into a frame script (such as calling function “doSomething()” on frame 1).
  2. In order for the imported SWF’s Actionscript to properly communicate with the Flash container, it must be prefixed with “_root.”; this corrects a scope issue and forces the Captivate movie to send the Actionscript call to its parent. The full line of Actionscript in the blank Flash SWF looks like this:
    _root.doSomething();
  3. The container SWF must contain the corresponding function. Something like this:
    
    function doSomething() {
       //do something
    }
    
  4. When the Captivate SWF’s play head reaches the frame containing the embedded SWF, any Actionscript contained in that embedded SWF is executed.

Click here to see a functioning sample. You can download a ZIP containing the source files here.

This is a simple solution, but it suffers from scope creep and is difficult to maintain. Who really wants to import a SWF every time they need to make an Actionscript call? I sure don’t. And if you ever want to change your Actionscript code, you need to re-export the SWF from Flash, and update the imported SWF in Captivate. Yuck.

Isn’t there a better way?

What about Javascript?

I got to thinking about it, and wondered (again) “Isn’t there a better way to do this?” Then I remembered two things: That Captivate supports Javascript calls, and that SWFObject — arguably the best way to embed Flash SWFs onto a web page — supports passing Javascript variables to a Flash SWF. What if I could make the Captivate SWF communicate with the Flash container SWF via Javascript and SWFObject?

Sad to say, no dice! SWFObject only passes variables when the Flash container SWF loads. I need to pass variables at various times, not just at ‘onload.’

Even though SWFObject was quickly shot down as a communication method, it got me thinking about Javascript as an alternative. Versions of Flash prior to Flash 8 could handle small snippets of Javascript via GetURL, but the GetURL hack is clumsy at best. I knew I didn’t want to go that route. But hang on a minute… what about Flash 8’s ExternalInterface class? It was designed to make Javascript-to-Actionscript communication a breeze! Having never really used it — it’s only supported in Flash Player 8+ and we’re still stuck supporting Flash Player 7 at the office — I decided to give it a whirl. I quickly created this example using Adobe’s tutorial [link no longer available]. First thoughts: Very intriguing and easy to get up and running, but can this be applied to Captivate SWFs loaded into Flash?

The short answer is… YES!

The new solution: Flash’s ExternalInterface class (Actionscript 2.0)

First I laid out the objectives for my experiment:

  • Make the Captivate SWF call the Actionscript function unload() (located in the Flash SWF) via Javascript
  • No variables would be passed… I wanted to keep things as simple as possible

I began editing the code from the aforementioned Adobe example, and in a few short minutes my proof-of-concept was up and running! I was amazed at how quick and easy it was… ExternalInterface was much easier to use than I anticipated.

Here’s what I did:

Step one: Add two lines of Actionscript code to the Flash container


import flash.external.ExternalInterface;
ExternalInterface.addCallback("unload", this, unloadSWF);

Step two: Add two small Javascript functions to the HTML page


//Detect Flash container movie
function getFlashMovie(movieName) {
   if (navigator.appName.indexOf("Microsoft") != -1) {
      return window[movieName];
   }
   else {
      return document[movieName];
   }
}

//Function to be called by Captivate
function captivateUnload() {
   //Calls "unload" method established in ExternalInterface Actionscript code
   getFlashMovie("simpleSwfLoader").unload();
}

Update: In my subsequent testing, using document.getElementById() works fine in place of the getFlashMovie() function. While some developers warn against using getElementById for grabbing Flash SWFs, my tests — using SWFObject as the embed method — were successful in the following environments: WinXP (FF2, FF3, IE6, IE7, Safari 3) and Mac OS X (Safari 3, FF3, Opera 9.5). You can still use getFlashMovie if you prefer.

Step three: Add the Javascript call captivateUnload() to the Captivate button.

That’s it! Really simple, huh? I must admit I was expecting it to be much more complicated.

How it works

As I mentioned earlier, I’m no expert on the ExternalInterface class, but I’ll try and explain what’s going on here. Let’s work backwards and start with the Javascript call in Captivate. Here are the source files if you’d like to use them.

The Captivate file

Captivate Button OptionsIn my example, I’m using a button to call a Javascript function named captivateUnload(). This Javascript function is located in the HTML file.

The HTML file

Moving to the HTML file, we see two functions. The first function, getFlashMovie(movieName), returns the Flash SWF as a Javascript object. This allows us to add functions to the SWF object. This is critical because Flash’s ExternalInterface class will listen for functions attached to the SWF object.

In my example, the Javascript function captivateUnload() attaches the Javascript function unload() to a SWF named simpleSwfLoader:


function captivateUnload() {
   getFlashMovie(simpleSwfLoader).unload();
}

By itself, this script won’t do much. In fact, it will throw an error in your browser if it doesn’t detect the accompanying ExternalInterface Actionscript code in your Flash SWF.

The Flash file

In the Flash file, the first line of Actionscript simply tells Flash to import the ExternalInterface class.

import flash.external.ExternalInterface;

The second line is where the action’s at (no pun intended… well, maybe a little!).


ExternalInterface.addCallback("unload", this, unloadSWF);

ExternalInterface’s addCallback method basically tells Actionscript to start listening for Javascript functions that have been attached to the SWF object. In our scenario, the unload() function has been attached to the SWF object.

The three parameters ("unload", this, unloadSWF) specify exactly what to listen for (a function named “unload”), where to listen (“this” SWF), and what to do when the SWF hears the correct bit o’ Javascript (execute a function named “unloadSWF”).

So for this example, the Flash SWF will execute function unloadSWF() when it hears Javascript call a function named unload() that is attached to a SWF named simpleSwfLoader.

Got all that? I know it sounds confusing (it still makes my head spin a little), but it’s actually pretty straightforward. Here’s a diagram for you visual learners:

Flow of scripting calls

And that’s the whole enchilada.

Let me remind you that this is a very simple example, and I’m sure this technique can be harnessed to do much more! Also, this example uses ExternalInterface for Actionscript 2.0. Flash CS3’s new Actionscript 3.0 uses slightly different code, but the concept is the same.

If any of you find this tutorial useful, or think of new ways to utilize this technique, please let me know by adding a comment.

Thanks, and good luck!

Embedded SWF technique source files  |  ExternalInterface technique source files

Today’s bit o’ knowledge: Firefox Web Developer Extension

today i learned about chris pederick’s ultra-handy Web Developer Extension for Firefox. yeah yeah yeah, i know it’s been around for a while, but i never TRIED it until today. i wish i had tried it sooner!

among its many features is the ability to toggle outlines on and off (looking at other sites’ block-level CSS is fun in a voyeuristic way), as well as the ability to disable a site’s CSS, images, javascript, cookies and more! it makes it really easy to examine the nuts-and-bolts of a web page’s structure/design without doing a save-as and opening in an editor like dreamweaver. me likey mucho.

http://chrispederick.com/work/webdeveloper/