<param name="flashVersion" value="8" />

The current flash version in my browser is: 9,0,115,0, and up until now, the version checking code worked in such a way that if the version declared in the param is lower than or equal to the installed version, the Flash content will be displayed, and otherwise you get the alternate content – in this case, a request to download the latest player. After playing around with it, I saw that either I had to change the version to 9 in the param, or remove it altogether. In other words, all of a sudden, IE requires the exact flash version of the player, rather than the version of the movie. Madness…

The workaround for that, was to include an iteration of version checking in the script – first, you check for the movie’s version, as defined in the param, if that fails, you increase the version three times, until you either get a success, or all four attempts fail.

} else if (this.ie && typeof (ActiveXObject) == "function"){
   //IE flash detection.
   //Try 3 versions higher than specified
   var maxCount = Number(version) + 3;
   for(var i=version; i<=maxCount; i++){
      try{
         var flash = new ActiveXObject("ShockwaveFlash.ShockwaveFlash." + i);
         return true;
      }
      catch(e){
        //continue
     }
  }
  return false;
}

Unfortunately, this is not one hundred percent future proof. If you’re publishing for 8, you might want to keep an eye on it after version 11. Unless, of course, IE recognises it as a bug and fixes it for later updates. Shall we all have a breath-holding competition?

In the meantime, this fix seems to work for IE7 and amazingly didn’t break in IE6 when I was showing the aforementioned project on a client’s PC. Miracles do happen.

Ok, so this is the bugfix issue. The second subject of this conversation, is the complete redesign of the ObjectSwap script, so it now uses objects, prototype functions, namespaces, and general best practices of OOP. Perhaps even more importantly, it now uses DOM event listeners instead of window.onload event.

The new code was written in July, and together with the latest bug fix, I feel it’s about time to release the update.

So here it is: Object Swap Updates

The need for a tree-view arose when I was adding a FAQ page to the Pediatric Center website. I didn’t want a long scrolling page, and it appeared to be a tedious affair to create all those internal links and anchors. A treeview structure seemed ideal for a FAQ, but then I couldn’t find anything usable on google (At this point you might say that my google skills could do with some polishing, and come up with a list of wonderful scripts that I completely overlooked…), and besides, good clean dynamic xhtml is still not that easy to come by.

The result is a Definition List Tree component – That is, a bit of JavaScript code that you can add to your page to create a treeview component out of a humble DL.

The Definition List xhtml:

The script will operate on any definition list on the page that has the class attribute “tree”, and ignore all others. If you’d rather use a differnt className or operate on all DLs regardless of class, you could change the init() function so it either uses another className, or passes a null – in which case all definition trees on the page will be affected. You can call your tree a “spade” if you like, but I call my tree a “tree”.

Each term/definitions pair should only have one <dt> tag with its text enclosed in a hyperlink, and a single <dd> tag.

The <dd> tag can then include other html structures, such as paragraphs, tables, other lists etc.

The resulting tree structure can be used for multiple purposes, such as FAQs, sitemaps, menus, directories and other listings.

For example:

<dl class="tree">
<dt><a href="#">Are you open on the weekends? </a></dt>
<dd>The Brooklyn (Brighton) office is open all weekends, all holidays,
and in all weather conditions.</dd>
<dt><a href="#">Do you accept my insurance?</a></dt>
<dd>If we do NOT accept your insurance, it is either (a) because it is
very rarely seen in the areas we cover, or (b) because it endangers the
health of the patients it covers by making essential services difficult
to obtain. <a href="insurances.htm">Click here for a partial
listing of insurances we accept</a>.</dd>
</dl>

The JavaScript:

The DLTree script needs to be linked at the head of the html page in the usual manner:

<script language="JavaScript" type="text/javascript"
src="scripts/DLTree.js"></script>

 …and is executed with the window.onLoad event, using a function that works without conflicting with the window.onload event of any preceding scripts.

At the top of the script, there are a few customisable variables:

//Icon images
var plus = "url(images/plus.gif)"
var minus = "url(images/minus.gif)"
//Padding for the icons
var padding = "14px"

These variables refer to the plus and minus icons that display the state of each node – plus to expand a collapsed node, and minus to collapse it. You need to create your own graphics here and place them in the images folder. The url for images can be changed here to suit your own folder structure, and is relative to the html document, rather than the javaScript. The images can be safely omitted, or designed to look like anything that indicates tree nodes. The padding variable corresponds to the space that the image takes up, including a bit of horizontal padding (for example, padding of 14 for an image of 12 pixels).

Expand All / Collapse All:

To expand & collapse all the nodes in the tree, you can add two links to the top or bottom of your page:

<p><a href="#" onclick="expandDLTree('tree')">
Expand All</a>&nbsp; &#8226; &nbsp; <a href="#"
onclick="initDLTree('tree')"> Collapse All</a></p>

Examples and Download:

The downloadable example contains a simplified excerpt from the Belilovsky Pediatric Center FAQ page, and contains all the xhtml and JavaScript mentioned above, including the treeview icons.

Download the DLTree code and examples.

In my case, it was both. After delving into numerous Internet sources, with some trial and even more error, I finally distilled a solution that, with slight adjustments, works for both JavaScript and Flash.

The basic principle is to trick the browser into thinking that a different image, with a different name, is being loaded. This can be achieved by appending a constantly changing variable into the url of the loaded image:

myImage.jpg?nocache=" + new Date().getTime();

The getTime() method of the Date object returns the number of milliseconds since January 1, 1970 to this date, (or another date specified in the instance). This is perfect for us, because this means that you get a unique number, each time – unless you can refresh faster than a speeding millisecond…

You could also play with the Date object’s methods and exchange getTime() for getHours() or getDate(). This would refresh the images every hour or every day, keeping them in the cache for the current session, which could be useful in some instances.

In JavaScript all you need now is to assign this to the src property of an image, for example:

var cam1 = document.getElementById("cam1");
cam1.src = "../images/cam1.jpg?nocache="
+new Date().getTime();

If you trace out the resulting src or nameProp of the image (I tend to use alerts for this), the returned string will include the url encoding – but will display the correct image, fresh from the HTTP oven.

In Flash you’d use essentially the same syntax, but it’s slightly more complicated. If you attempt to load an image with this url from the IDE, it won’t find the image and will return an error instead. However, it will work fine when embedded in a browser.

To make it work in both, you need to test for the playerType first, before adding the url encoded variable:

var loader:MovieClipLoader;
var viewLoader:MovieClip;
var url:String = "images/catalogue/collection/cat1.jpg";
if (System.capabilities.playerType == "PlugIn"
|| System.capabilities.playerType == "ActiveX"){
      url+="?nocache="+new Date().getTime();
}
loader.loadClip (url, viewLoader);

 

 

This solution is not only limited to images – it can also be used when loading other file types that you wouldn’t like cached, such as XML, SWFs and other files or assets.

Your life might get somewhat easier when it comes to headings, with various CSS Image Replacement techniques. But they’re not perfect either, and for menus you need be able to hyperlink the image.

Available Solutions

So what can you do?
1. Use CSS to format your textual menu to it’s best abilities, using the same old fonts and maybe a background image to make it look nicer. Don’t even think about using an interesting font like Arcitectura, or adding some layer effects in PhotoShop, because then you’ll have to use images.
2. Employ images, which is not very semantic and requires you to add lots of additional markup, such as img and alt tags, and then you’ll need to add JavaScript calls for rollovers, and change the image of the current menu item on each page. What’s next? Design with tables…?
3. Design a Flash navigation bar, which is again not very semantic, SO friendly, or accessible. I’ve nothing against Flash, in fact, I I’m a huge fan. It can be used to great effect to add an extra dimension to the website with animation and interactivity. But just like salt and pepper, you need to know when to stop adding it. Graphics or drop down menus are not a good enough reason for a Flash menu – these can always be accomplished by dhtml. A Flash navigation needs to be exceptional (or at least quite interesting) to justify itself, and even then you’ll need to add textual navigation somewhere on the page, at least for the search engines.

Most of my xhtml websites up to date have been achieved with the first method. Take a look at my own website, for example – it uses CSS and background images for formatting, and the font defaults to a generic serif. Even then, it took a lot of work and a bit of extra markup to achieve the look.

NavSwap:
My latest website project (not yet published as this goes to “print”, but soon to come) is for a glossy fashion wholesaler, and that meant top-notch graphics, even for the menu. For this I came up with option #4 – NavSwap, which happens to be the object of this article. It took some code wrangling to write, but is quite easy to implement.
You can download the script and examples here…

NavSwap serves two functions:

1. Swaps semantic xhtml into images, using unobtrusive JavaScript. That is, if JavaScript is unsupported, you get an xhtml text menu, otherwise you get images, complete with alt tags generated on the fly.
2. Automatically swaps images on rollovers and swaps the current menu item with an active state item on each page.

The html markup:

<ul class="nav" id="nav">
<li><a href="index.htm">Home</a></li>
<li><a href="about.htm">About</a></li>
<li><a href="awards.htm">Awards</a></li>
<li><a href="emporium.htm">Emporium</a></li>
<li><a href="suppliers.htm">Suppliers</a></li>
<li><a href="contact.htm">Contact</a></li>
</ul>

This is mostly all the html you will require. The script will cycle through the menu items and use each item’s text value for the name of the image that will be replaced (converted to lowercase, with extension and directory path added), and also uses it to generate the alt text.
If, however, your menu item’s text requires spaces, characters or markup unsuitable for file names, or is duplicated across menus (with different images), or for any other reason, you can assign a className to the item’s to override it. For example:

<li><a href="joinus.htm" class="joinus" >Join Us </a></li>

You can also add an idto the body tag. The id’s value should correspond to the text of the menu item, or the overriding className. This will mark the page as active, and the script will automatically change the image of the corresponding item to the active state:

<body id="home">

Organising The Images:
Next, you’ll need to prepare the images using PhotoShop or your favourite image editing software. You will need to create images for two or three different states, using the same file names (home.jpg, about.jpg etc.) but organised in different directories:

1. Up: The images as they appear in their normal, or “up” state.
   Default directory: “images/nav_up/“.
2. Over: The rollover images.
   Default directory: “images/nav_over/“.
3. Active: The active images for each page. By default, the script uses the Over images for the Active state. But it is possible to create separate images for this purpose, by switching a variable in the script.
   Default directory: “images/nav_over/” – but can be changed, for example, to: “images/nav_active/”.

These paths are user-customisable by passing the through the following variables in the navSwap.js file:

var navUpPath = "images/nav_up/";
var navOverPath = "images/nav_over/";
var navActivePath = "images/nav_over/";


- Or by passing the new directory paths to the navSwap() method (see below).

The names of the images should be the same throughout the directories, and consistent with the text of the menu items. For example:

<li><a href="index.htm">Home</a></li>
--> home.jpg
<li><a href="about.htm">About</a></li>
--> about.jpg


The JavaScript:
The text menu will be swapped for the images using JavaScript. To do this, you need to add the link to the external script to the head of the page:

<script type="text/javascript"
src="scripts/navSwap.js"></script>

And place a call to the method right after the menu:

<script type="text/javascript">
navSwap("nav", 90, 30, "jpg", "images/nav_up/", "images/nav_over/");
</script>

For each menu or submenu in your document you need to use a separate call to the navSwap method, passing the following optional parameters: (id, w, h, suffix, upPath, overPath, activePath):

1. id: The id of the menu <ul> that is to be replaced. If this parameter is not passed it defaults to “nav”. However, it can be particularly useful if you have multiple menus or submenus. Each of these will need its own id.
2. w: Width of the images that replace the menu. The images should all be the same width if this parameter is used.
3. h: Height of the images that replace the menu. The images should all be the same height if this parameter is used.
4. suffix: The default is “.jpg”, but could be changed to “.gif” or “.png”.
5. upPath: The up state images path.
6. overPath: The over state images path.
7. activePath: The active state images path.

The script works with multiple menus, as long as each has it’s own id, so you could combine this method with drop-down menus and other techniques.

Design Issues
Of course, menus don’t always come in the shape of a list, so you will need some CSS formatting to finish off the look. You can use CSS to position the menu, add margins or padding, and maybe change it from vertical to horizontal ( .nav li {display:inline}).

Also, since we’re adding the JavaScript unobtrusively, you could add a bit of extra styling to the menu with CSS, to make it look as good as it can when JavaScript is disabled.

Unfortunately, I couldn’t find a way to detect if images are disabled in the browser. If anyone knows how to do that, please let me know. If, however, images are disabled, this technique at least ensures that you see their alt tag replacements instead. This looks better in Firefox than in IE, but at least it’s still useable.

Examples and download:
You can see the example in action here.

The script, example and all supporting files can be downloaded here.. If you want to have a look under the hood, the script is commented throughout.

I hope you find it useful.

Since the ObjectSwap article appeared on this blog in April, the code has changed a number of times. To reflect those changes, and give you a bit more insight on how to use it, I bundled up a few ObjectSwap Examples together with the script:

In addition to that, I sent an updated version of the article to SitePoint, and I’m happy to announce that it’s been recently published: ObjectSwap: Bypassing the ActiveX Activation Issue in IE.

I hope this script has been as useful to you as it has been to me. Thank you for your great feedback and for your patience with all the changes and bugfixes. I hope that no more will be necessary, but if there are, please let me know.

Karina

Microsoft’s decision to change the way ActiveX objects are handled in Internet Explorer, following the patent law suit by EOLAS, has left the developer community in uproar. Soon all the ActiveX controls in Internet Explorer, among them Flash and Shockwave, will need to be activated by a click or a tab and an enter key before they can interact with the control. This is bound to impair the user experience of any website that embeds Flash – and there are many such sites out there - and make a good deal of trouble for the Flash developers, who are left to clean up the mess.

Available Solutions:

You can bypass the activation requirement by using an externally linked script, such as JavaScript, to embed the ActiveX content. There are currently available solutions for Flash, such as SWFObject and UFO. These work well for embedding new Flash content using JavaScript. But what about existing <object> tags, which will need to be rewritten, or browsers with disabled JavaScript? These would require an alternative solution.

ObjectSwap:

Neo-Archaic’s ObjectSwap solution (downloadable from www.neo-archaic.net/scripts/objectSwap.js) takes all these issues into account. It captures all existing <object> tags and replaces them with themselves. This forces an automatic activation in Internet Explorer, while leaving other browsers alone. Similar solutions have been developed in parallel, but this article will only concern itself with ObjectSwap. Although this solution was developed primarily with Flash in mind, it should also work with other ActiveX controls, such as Shockwave. The script affects all the <object> tags in the page, but the user can exclude specific objects by setting their class name to  ”noswap”.

Implementation:

ObjectSwap was written with a view to make implementation as easy as possible, with minimum disruption to existing code. The only change needed to your html page is placing the script in the <head> tag for every page that includes ActiveX objects, like this:

<script type="text/javascript" src="scripts/objectSwap.js"> </script>

After that, you can keep on using your favourite technique for embedding ActiveX content. For Flash it’s either the Adobe/Macromedia default setting using object/embed tags, or the standards compliant technique that uses only the object tag (better known as Flash Satay).

How it Works:

First, the script cycles through all the <object> tags in the html source code and retrieves their outerHTML value:

var objects = document.getElementsByTagName ('object');
for (var i=0; i<objects.length; i++){
  var o = objects[i];
  var h = o.outerHTML;

Since Internet Explorer does not include any of the Object’s param tags in its outerHTML (or innerHTML), they need to be extracted separately into a string:

var params = "";
for (var j = 0; ji<o.childNodes.length; j++) {
	var p = o.childNodes[j];
	if (p.tagName == "PARAM"){
			....
		params += p.outerHTML;
	}
}

The generated  “params” string is spliced into the outerHTML code:

var tag = h.split(">")[0] + ">";
var newObject = tag + params + o.innerHTML + " ";

And, finally, the new generated html replaces the original:

o.outerHTML = newObject;

Hiding The Objects:

There are still a few things to be done. First of all, we want to prevent the objects from loading twice - once when they are initiated in the html code, and again after they are swapped. This is achieved by writing a new stylesheet to the document before the page loads. The style uses display:none to take the object out of the document’s flaw and delay their loading until the swap is complete:

document.write ("<style id='hideObject'> object {display:none;} </style>");

After the swap, the style is disabled and the objects are allowed to load:

document.getElementById("hideObject").disabled = true;

Initiating The ObjectSwap:

The function must be called after all the objects have loaded by binding the objectSwap() function to the window.onload event. The catch, however, is that other linked scripts in your page might have their functions bound to the same event; the last script to do so will override all the earlier bindings, causing other scripts to fail. This is resolved by catching existing functions bound to the event, and calling them as well:

var tempFunc = window.onload;
window.onload = function(){
	if (typeof (tempFunc) == "function"){
		try{
			tempFunc();
		} catch(e){}
	}
	objectSwap();
}

This will naturally fail if following scripts use window.onload, so you must ensure that either this script comes last, or the following scripts use a similar technique.

Flash Detection:

So far, so good. But since we’re already using JavaScript, why not avail of the opportunity to add some Flash Detection to the mix? This can be achieved by adding a new param definition to the flash object, for example:

<param name="flashVersion" value="6" />

As it cycles through the parameters list, the script checks for the existence of this param and, if it finds it, calls the flash detection method. If it doesn’t find the Flash plugin, or the installed version number is less than the one required, the code turns the object into a simple <div> and displays the alternative content. This content must already reside inside the <object> tag, and display alternative text, images, links to the Flash installer, and so forth. The object tag normally ignores this content if Flash is present. Of course, you can also chose to ignore the flash detection option or use Adobe’s express installation for Flash 8 instead.

Browser Support:

The activation issue of ActiveX objects affects only Internet Explorer, and so most of the code will only affect IE. The flash detection code, however, needs to work with other browsers as well. This means that the objectSwap() function will be called for all the browsers, perform the flash detection service if required, but will only execute the Object Swap on IE, leaving other browsers unaffected.

Examples and Download:

You can find an example of this code in use on the Neo-Archaic home page and the images page in the gallery. Both pages use the Flash Satay method to embed Flash. The script is located here: http://www.neo-archaic.net/scripts/objectSwap.js .

A new examples bundle (last updated in Februray 2008) can be found here: ObjectSwap Update.