In part one of this series, we published a simple Captivate course and examined its file structure. In this part, we’ll take an in-depth look at the HTML generated by Captivate (using the SCORM 2004 publishing template) and clean it up as much as we can.
I’ll take the high road and avoid the ever-so-easy snarky comments about this code. Suffice to say it needs some serious cleanup; it’s obvious that multiple people with multiple coding styles have worked on this document, and no quality assurance team has run through it to ensure it’s clean and concise. For example, there is an entire block of code commented out at line 141 (commenting it out means it never gets used, and therefore is useless bloat).
There’s also an aborted attempt at using SWFObject from lines 214 to 242 — the object is declared, but never invoked. Never. Did you know this code has been shipping with Captivate for years? I’m amazed no one has bothered to clean it up (and yes, I have reported it to Adobe, but they chose not to act).
As irritated as I get looking at the code, this blog post is not meant to be a rant, so let’s be constructive and get to work cleaning this mess.
This document is incredibly hard to read due to all of the
This single step makes the HTML file much easier to read.
Cleanup task #2: Fix the doctype
Stepping through the HTML, the very first lines of code (lines 3-4) contain a conflict: the doctype says this is an HTML 4 (transitional) document, but the head element contains an XHTML lang declaration.
We’re in an HTML5 world now, so let’s use the HTML5 doctype. It’s 100% compatible with all browsers (even Internet Explorer 6), and all the cool kids use it. We can retain the lang declaration, too, with a few modifications. While we’re at it, let’s update the charset meta tag to the accepted HTML5 syntax.
Cleanup task #3: End the crazy
There are six
<script> blocks in our HTML file, and they are all inconsistent. For example, some have a “type” attribute, some have a “language” attribute, some have both, and some have neither. This is a sure sign of multiple authors working on the document over a long period of time.
Going through the
<script> block, we can clean them up as follows:
- Line 8: Since we’re using the HTML5 doctype, we can simplify it to remove the “type” attribute.
- Line 9: Leave as-is.
- Line 10: Remove the “type” and “language” attributes.
- Lines 17-25: This entire block is never invoked and is completely useless. Delete it.
- Lines 37-73: The contents of this block need cleanup, but we’ll handle that later one. For now, just remove the “type” and “language” attributes.
- Lines 74-77: There is no need for a separate
<script>block here; merge the contents with the previous
Cleanup task #4: Remove inline scripts and styles
<body> element contains two inline attributes: a style attribute, and an onunload handler. It’s an accepted best practice to leave your markup as clean as possible by removing inline styles and scripts when possible, so let’s create a new <style> element to hold the CSS, and move the onunload handler to our captivate.js file (just paste
window.onunload = Finish; at the bottom of captivate.js).
If you’re not sleeping yet, you’re probably wondering why creating a
<style> block is better than leaving the style attribute in the <body> tag. For this project, I know I will be adding more CSS declarations to the
<style> block, so we may as well set it up now.
Cleanup task #5: Cure
There are two sets of
<center> elements on the page that can be replaced by adding one line of CSS to the top of the page.
Delete lines 16, 47, 66 and 72. Add
text-align: center; to the
body selector in the
Cleanup task #6: Edit the
For accessibility and usability purposes, it’s usually a good idea to include a
For this Captivate template, it’s probably best to remove the SWF from the
Cleanup task #7: Get rid of the
<table> whose sole purpose is to make the SWF vertically centered on the page. For our purposes, this is unnecessary because most courses launch in a popup window that has been sized to fit the course.
<table> that is meant to make the embedded SWF look nice on the page actually causes a significant problem — the table has cellpadding and cellspacing set to 7, which means the SWF will never extend to the edge of the window. When you’re trying to make a perfectly-sized popup window for your course, this cellpadding and cellspacing will cause scrollbars to appear, driving you bonkers!
Also, it’s widely accepted that tables shouldn’t be used for layout purposes, anyway, so it’s best to get rid of the
Our HTML file is starting to look pretty sweet!
- Lines 23 through 36 appear to be safe to move into the document’s
<head>, which means it’s safe to move to our captivate.js file. Just cut and paste — place the script at the very bottom of captivate.js.
- Lines 38 through 47 use SWFObject 1.5 to embed the SWF. We can move this code, but it will need to be wrapped in an onload event or else it will break the page. In a later step, we will upgrade SWFObject to 2.2, which helps us optimize the Captivate template even further.
- Lines 49 and 50 can be moved, but will also need to be wrapped in an onload event.
While moving the SWFObject code, we can also clean it up a bit:
- Line 39 is not necessary because quality = high is Flash Player’s default.
- Line 41 is not necessary because SWFObject is already set to use “Captivate” (the second argument passed on line 38) as the ID for the SWF.
- Line 42 is not necessary because wmode = window is Flash Player’s default.
- Line 45 is not necessary because it does nothing, it’s a completely gibberish line of code. I suspect it was a placeholder put there by a developer years ago, and no one has bothered removing it. It has shipped with Captivate for years.
- Line 46 is useless; the redirect URL is only invoked when two criteria are met: 1) the embed markup is present in the HTML, and 2) the visitor does not have the required version of Flash Player. This Captivate file is using SWFObject to write the embed code. SWFObject has its own check for Flash Player (argument #5 on line 38); if the minimum version specified is not found, SWFObject will not write the embed code into the HTML. This means requirement #1 listed above will never be met, which means the redirect URL will never be invoked.
Update: Upon re-reading this post, I noticed even more issues with the SWFObject code: line 40 (‘name’ is not a param, it’s an attribute) and line 43 (bgcolor param isn’t needed, the color should be specified as the 6th argument in the SWFObject declaration). I won’t update the examples because we’re replacing SWFObject 1.5 with 2.2 in the next part of this series, so the entire SWFObject code block will be replaced.
We can pare it down more later, but this is a great start.