Introduction

So the first post about moo.fx introduced a simpler way of hooking up sliding panels to moo.fx and while it worked well in Firefox it had issues with Internet Explorer. The second version addresses some shortcomings of IE and also describes a workaround for other issues. The last bit of news is that this article also includes a ZIP that you can download that has a complete and functioning demonstration of the library and will run as is in Firefox and Internet Explorer.

Why this library?

So you ask yourself, why is this implementation important and what does it do to help me? Here are a number of reasons why this library can make life easier and hopefully will give you a reason to use it.

• It is search engine friendly (SEF) because the HTML is pretty clean, has no Javascript in the body and the content is visible by text only viewers like Lynx or spiders.
• You don't need an ID on any of the elements so you don't need to concern yourself with creating unique ID's at runtime.
• It does not know the ID's of any slide panels and never needs to know. Because it doesn't care, you won't get an error if the element is missing and you also remove the need to explicitly test for it.
• You can have zero (yes zero) to N slide panels without writing any additional code.
• The HTML is clean enough for a web designer to understand and there is no Javascript to explain or tweak on a per page basis.
• It frees up valuable screen real estate but leaves important information for your visitors to see and spiders to read.
• You can style the slider via class name and/or ID.

How it works

Besides moo.fx, the rest of the magic is in the TSlidePanels Init method. The Init method uses getElementsByClassName from the moo.fx dom class to locate all of the slide panels. We then walk each of those elements to locate the toggle and content classes - this is done with getDescendantNode. We then connect the onclick event to each toggle and the hard work is done.

So far we have found the slide panels but haven't made them do anything at all. When the user clicks on a toggle, we create an effect object and start it up. What we have done is postpone the initialization in the hope that we can speed up page loads and reduce memory usage.

The usual problems

1. The method that is called doesn't have access to the this operator but instead gets an event object which contains different information if you use Internet Explorer or Firefox. The workaround is that we try to sense the browser and access the data that we want. This is the code in a nutshell.

var self = (e.target) ? e.target : e.srcElement;

2. We now have the HTML element that was clicked (see graphical problem below) but not the TSlidePanel object itself which contains much of what we need. Luckily the Init method stored a pointer to the TSlidePanel object in the toggle HTML element so we can reference it when we need to. Now we have a valid object that tells us what HTML element holds the content, which one is the toggle and which element may have a glyph.

3. The graphical problem is part of Internet Explorer. Firefox correctly identifies the toggle HTML element that was clicked even if that element was holding an IMG tag that was actually clicked. Internet Explorer on the hand identified the toggle element but incorrectly passes back the IMG element as its source so we lose access to our TSlidePanel object. To get around this we use CSS to display the image inside the toggle and avoid embedding an IMG. The demo has an example of this.

The other magic is in the CSS, so refer back to the demo if you have any questions.

Sliding Panels Demo Zip
Sliding Panels Demo Link

---