Last week I pushed out some major updates to my most well-known piece of work to date, Shadowbox. This update finally brought version 3 of the code out of beta and into a much more robust and ready state. Overall I’m very happy with the release. It took much longer than I expected (for a lot of different reasons), but the time it took just helped to produce a better product in the end.

In this post I hope to reveal some of the steps I took to improve the code base and some of the gotchas that developers who are experienced with the library might encounter when upgrading to the latest version of the code. If you run into any snags that are not outlined in this post, please let me know so I can consider making further adjustments to this post and/or the documentation to clear up any confusion.

Initialization

The 3.0 beta expected the developer to specify some dependencies in Shadowbox.init if they were different from the defaults. These included the players, language, and adapter to use. The script would then check these settings and load any needed files by appending <script> tags to the head of the document. However, many users had trouble understanding these settings and couldn’t get the script to work properly as a result. This often happened when a user desired to play a certain type of content and neglected to load the appropriate player classes during initialization.

This behavior has been modified in the final version of 3.0. All player, language, and adapter dependencies are now specified when you create your own custom build of the code. Instead of being requested on every page load, all necessary files are compiled into the code up front. This change should make it much easier for users who are not familiar with the code to get it up and running quickly.

An added benefit of compiling everything into one file up front is that no additional HTTP requests need to be made to the server for dependency files. This should significantly speed up your page load times and decrease the load on your server.

Setup

The ability to pass in options via markup has been removed from the script entirely. There are several reasons for this. The first is that putting a JSON object into HTML markup is just not good practice. When I first invented that feature, I thought it would be neat if someone were able to use Shadowbox using only HTML markup, and without touching JavaScript. So I added the ability to put a JSON hash in the page markup and eval it at runtime. However, in retrospect it seems a bit silly. After all, someone who is not comfortable using JavaScript certainly wouldn’t be comfortable putting JSON objects into their HTML!

The second reason is related to the first, and it is simply the use of eval on text that is included as part of the page. With the growing popularity of XSS and similar malicious attacks on website markup, using eval presents a major security vulnerability. I know that probably could have constructed some elaborate workaround using Crockford’s json.js, but I didn’t consider the extra weight worth it for a feature that was clumsy in the first place.

Now you will still be able to use custom options for your links, but you need to do it via Shadowbox.setup (several examples are available in demo.js, the same file that is used to run the examples on the Shadowbox website.) Setting up your links via HTML markup still works, just not with custom options.

Hacks

Another major step I took in this latest release was to eliminate the number of hacks in the code. The web by nature is one big hack, and client-side programming can get especially hacky especially with a product as complex as Shadowbox. However, I believe that it’s only good to resort to hacks when you need them and only after exhausting all possible (and reasonable) alternatives.

One hack that I wanted to eliminate completely was the use of a “dynamic property” in the CSS code. This code was used to dynamically calculate the height of the viewport in browsers that do not have support for position: fixed like IE6 (there’s a bit more to it, but that’s the basic gist of it.) However, it never sat particularly well with me. I’m happy to say that I was able to modify the code to not use any proprietary CSS properties in version 3.0 final. It now feels much cleaner, and it’s a lot more future-proof.

One more hack that I tried to eliminate is the use of browser sniffing via the user-agent string. While I wasn’t able to completely eliminate this (yet), I’m down to only a few instances of it now. The code relies a lot more on object/feature detection instead. This is also much more future-proof and should go a long way in helping to support as many browsers as possible.

Speed

The entire codebase has been streamlined to run faster and more efficiently in every browser without sacrificing any of the existing functionality. I ran quite a few tests to determine the most efficient way to structure the CSS and conduct the animations while keeping memory usage down. In the process I squashed several memory leaks in IE6 that caused that particular browser to slow down after reloading the page several times. In short, the whole experience should be smoother and more consistent for users, no matter what platform they are on.

Source

The new home for the Shadowbox code is on GitHub. Although the code is not released under an open source license, I have always made the source available for debugging and learning purposes and I intend to keep it that way. Please report any bugs that you may find on the new issue tracker.

I hope you enjoy the latest release of Shadowbox.