Of course I still support IE, and I don’t want to bring that up for debate at this time. That poor horse has been long gone for quite a while, so we can all put our sticks down for a bit. I have, however, taken a more aggressive personal stance in my lack of attention to detail when it comes to that browser family.

A tweet by Jeffrey Zeldman really got me hooked to the prospect of further adoption of CSS3:

When all browsers except IE support CSS3, it will test the limits of progressive enhancement as a design philosophy.

With my further embrace of and focus on CSS3 came an increased interest in other bleeding edge techniques in Web design, primarily CSS animation.

Does CSS animation belong?

One of the ways in which I’ve been trying to raise the overall comprehensiveness of my projects is incorporating CSS animation where it may enhance the experience of a particular design. Animation in CSS has, from time to time, been a hot topic in Web design. Does animation belong in CSS? Does it constitute behavioral modification to the document, and therefore find its proper place through JavaScript? Is animation technically behavior?

Trying to classify the true placement of animation has proven to be a personal challenge to me. I can see both sides of the argument. I agree that animation can be correctly implemented through JavaScript, as has been done for some time. On the other side of my personal coin, I see that animation is more of a visual stimulus as opposed to direct behavioral change (e.g. updating the DOM with data received via AJAX).

The basics of CSS animation

As with all new technologies, you should take a minute to familiarize yourself with implementation as well as implication to make a more educated (and therefore accurate) decision to (not) use it.

The WebKit team provided a very nice write up upon the release of a nightly build that supports CSS animation. In the post, an overview of animation with CSS is provided, as well as a bit of documentation and example.

The WebKit implementation of CSS animation has a bit of a learning curve, but once you decipher how it works, it’s quite elegant (in my opinion). Applying a CSS animation comes in two steps. You’ll first designate your style as you would normally, defining any properties you’d like, with the addition of something new: -webkit-transition.

-webkit-transition is actually shorthand for three transition properties:

• transition-property: The property to which the animation will be applied
• transition-duration: The length of time the transition will last
• transition-timing-function: Possibly better explained as the easing method you’d like to use

With these three properties, you’re provided a set of tools that can directly affect the richness of your designs, bringing the level of interaction up a notch or two. To make things even more elaborate, the WebKit team has also included support for comma delimited transition declarations, allowing you to animate multiple values using a single property declaration.

A finished implementation of WebKit CSS animation may look something like this:

div.message a.dismiss {
  opacity:0.2;
  -webkit-transition:opacity 0.3s ease-in-out;
}

div.message a.dismiss:hover {
  opacity:1;
}

If you’re using a recent build of WebKit that supports CSS animation, check out the example.

CSS animation can have dramatic affect on your designs, especially in Web application enahcements. Jonathan Snook recently published a screencast outlining his use of CSS animations while playing with Titanium, a platform I’m actively researching as well.

Jonathan’s use of CSS animation in his screencast really brings its potential to the surface. With animations such as the combination of scale and opacity to achieve stellar effects really helps to make CSS animations shine.

What should control animation?

Truly classifying CSS animation has been a personal challenge for me as a designer; what are your thoughts? Do you feel that animation belongs in the realm of style or behavior? Do you feel animation is something else entirely? Now that an option beyond JavaScript has surfaced, did that change your opinion? Do you see animation in CSS being continually adopted on a more consistent level when it comes to adding ‘that little something extra’ for those using an applicable browser?

Advertise here with BSA

Crop and Resize with GD

Above all, the most asked question was “why only ImageMagick“? I really don’t have a solid answer for that, other than the project itself was a way for me to get into using ImageMagick in a bit more detail than I ever had. I’m very happy to say that this version (as well as any future versions) now has equivalent ImageMagick and GD installations. You can choose one or the other in both the demo and download sections.

Demo: GD Crop and Resize v1.1

Demo: ImageMagick Crop and Resize v1.1

The demos and downloads have been removed temporarily due to a security issue. Replacements will be linked as soon as possible. Thank you for your patience. Please discontinue use as soon as possible until a revision has been posted.

Converting to GD wasn’t a major undertaking thanks to the helpful comments on version 1.0. It did take some time getting the slider to properly convey dimensions that would result in an accurate recreation of the image. One thing I have noticed is that the GD version seems to result in lower quality output when compared directly to ImageMagick. If you’ve got a server with both GD and ImageMagick installed, take a minute to use the same image in both demos to see what the differences are. I plan on looking into this much further, but if you’re a bit more knowledgeable on the subject, I’d love to hear what you have to say. Could the answer be that ImageMagick is simply a superior piece of software? I noticed that GD gives you the option to control the quality of images when using certain functions, so I left image output at 90% for the time being (the default is 75%).

If you have any positive or negative experiences with the new GD version, please feel free to post your findings either below, or in an email to me. I’d be greatly appreciative of any data that comes through.

Updates to the server side

There were a number of fixes that needed to be done to the server side of things straight away. First and foremost was Linux dependency. I must admit, a Windows server didn’t cross my mind when I was working on version 1.0, so I tried to polish things up a bit in that regard. The mv lines have been replaced, as well as an update or two elsewhere. There could very well be some more Windows-specific issues to be dealt with, unfortunately I don’t have any Windows servers at my disposal to test with. Feedback in this area will be particularly helpful.

A small series of updates I made was to the file upload process itself. The example now only accepts files with a MIME type of image/jpeg. Future versions will allow for more image formats, but I’d like to do some more research before including it. There are also some checks on the filenames themselves, as there were some issues with particular circumstances in version 1.0.

There was some logic repair regarding the $maxWidth and $maxHeight variables you can set in the first step. As per request, $minWidth and $minHeight have also been added. This should allow you to really narrow down what image dimensions will result using these variables in conjunction with the Cropper UI. One issue that has not been included yet is taking the minimum and maximum values set in the first step into account when users have reached the resize stage of version 1.1. This will be handled in a future release.

Finally, the last noticeable feature to be added server side was the inclusion of image rotation. When the final image is presented, image rotations of 90, 180, and 270 degrees will be available as well. You’re able to pull apart the code to retrieve which image you’d like to use, and can also include auto-generation using a form whenever you’d like. This was a larger hill to climb when it came to GD as none of the servers I have access to had PHP compiled with GD bundled, therefore giving me no access to imagerotate(). As reflected in the source, a function was written as an alternative, and appears to work just fine. It checks to see if imagerotate() is available before taking the extra CPU cycles doing it ‘by hand’.

Updates to the Cropper UI

I can’t credit Dave Spurr enough for his Cropper UI that powers the entire front end of the cropping mechanism this installation provides. He had made a number of updates after my version 1.0 release, so first things first I went ahead and upgraded to his most recent version.

The second most asked for feature was a specific alteration to the Cropper UI itself. Whether it be minimum dimensions, maximum dimensions, or something else, it seemed like many people would like to use the script, but the openness of the Cropper UI was in fact a limitation. I made an effort to indicate that Dave Spurr included many of the requested features right out the box and documented them well on his website. To help with the version 1.1 demo, I’ve included a few Cropper UI instances to demonstrate its robustness. When you check out the demo, you’ll see a new option to choose the crop type you’d like to use. I’ve included the following by default:

Basic crop

Includes the most basic version of the Cropper UI. Unrestricted as far as crop dimension is concerned.

Ratio (16:9)

A 16:9 ratio will be applied to the Cropper UI. There are no restrictions for width or height.

Minimum Dimensions (200×200)

The Cropper UI will require a minimum 200px by 200px crop area and will not allow anything less.

Minimum Dimensions (200×200) with Ratio (1:1)

The Cropper UI will require a minimum 200px by 200px crop area and will not allow anything less. It will also apply a 1 to 1 ratio when adjusting the crop area.

Maximum Dimensions (200×200)

The Cropper UI will require a maximum 200px by 200px crop area and will not allow anything less.

Maximum Dimensions (200×200) with Ratio (1:1)

The Cropper UI will require a maximum 200px by 200px crop area and will not allow anything less. It will also apply a 1 to 1 ratio when adjusting the crop area.

Fixed Dimensions (200×200)

You’re provided with a crop area at a fixed size of 200px by 200px. The drag handles are also removed as an added convenience.

Minimum Dimensions (100×100) & Maximum Dimensions (200×200)

With this option, you’re limited to a crop area range scaling from 100px by 100px to 200px by 200px.

The Cropper UI is quite impressive in and of itself as you can see by the number of options you can apply by changing some values. For example, one thing I didn’t include in the demo is a Cropper UI that is limited to minimum and maximum dimensions as well as an aspect ratio of 1:1. You can easily invoke a Cropper UI with these attributes by creating a new file (lib/init_cropper/min_max_ratio.js for example) and inserting the following:

function onEndCrop(coords, dimensions) {
	$('cropX').value = coords.x1;
	$('cropY').value = coords.y1;
	$('cropWidth').value = dimensions.width;
	$('cropHeight').value = dimensions.height;
}

Event.observe( window, 'load', function() {
	new Cropper.Img(
		'cropImage', {
			ratioDim: { x: 1, y: 1 },
			minWidth: 200,
			minHeight: 200,
			maxWidth: 300,
			maxHeight: 300,
			onEndCrop: onEndCrop
		}
	);
});

Swapping in this JavaScript would invoke a new Cropper UI for your image with a minimum dimension of 200px by 200px, a maximum dimension of 300px by 300px, as well as an aspect ratio of 1:1. Going further, you’re also able to specify a minimum or maximum for a height or width alone. This will result in a Cropper UI with handles only on the top and bottom if you wish. I would definitely suggest checking out the official website for Dave Spurr’s Cropper UI for more details

Download & installation instructions

Installation is very straightforward. Download links to follow.

1. Download the GD or ImageMagick version
2. Extract
3. Upload to your webserver
4. Give write permissions to the working folder and subfolders
5. Begin using the demo

Download GD Crop and Resize v1.1 (.zip)

Download ImageMagick Crop and Resize v1.1 (.zip)

The demos and downloads have been removed temporarily due to a security issue. Replacements will be linked as soon as possible. Thank you for your patience. Please discontinue use as soon as possible until a revision has been posted.

Many times, if you’re experiencing odd behavior such as pages turning up blank, there is an issue with write permissions on your server. The demo will need write access to the directory in which it is stored as well as the working folder and all folders within it. Errors with the code itself will more than likely be output to the screen. If that happens, please feel free to post your errors at your earliest convenience.

What about AJAX?

Another request that popped up more than once was a request for an AJAX version, something that didn’t require the page to reload. I thought about working out something such as that but quickly dismissed it, at least for now. My intention with this project was to provide something which would be used by the widest audience possible. Too many times have I seen examples too far into their own development to prevent me from writing something from scratch. In my opinion, an AJAX version of this example would prevent easy adoption and inclusion for many developers. AJAX may be a possibility for a future version, but I’d like to seriously consider as many angles as possible. This directly relates to the (lack of) design when looking at the demonstration. I wanted to keep things minimal in order to create the least work for anyone who wants to try incorporating this into something they’ve written.

I hope at the very least, the GD version presents itself as useful to at least a few people over the coming months. I do plan continuing work on future version, I simply hope it doesn’t take as long as this revision has. Please provide any comments you’d like, especially bug reports, and enjoy the demo!

Advertise here with BSA

Moving on, Google is using tables to mark up their driving directions provided via Google maps, but in my opinion, there’s a much better way.

There is actually quite a bit of information provided in simple driving directions. For the purposes of this article, I’d just like to focus on the directions themselves, as opposed to the content offered before and after, as well as the maps that are (usually) included.

Driving directions at their core

At the very least, when providing driving directions, you’re compiling an ordered lists of steps that need to be followed in order to navigate from point A to point B.

<ol class="driving-directions">
  <li>Head southeast on Crossgates Mall Rd - 0.2 mi</li>
  <li>Turn left onto the Washington Ave Ext E ramp
    to I-90 Thruway/I-87 - 407 ft</li>
  <li>Merge onto Washington Ave Ext - 0.9 mi</li>
  <li>Continue on Washington Ave - 3.9 mi</li>
  <li>Turn right at Robin St. - 417 ft></li>
</ol>

While a single ordered list could be considered acceptable, there is quite a bit more information provided that has semantic value. For instance, in each step of the ordered list, there is detail given as to what actions should be taken, as well as a measure of distance. To me, this is a good place to include a definition list. It seems fitting to mark up this pair of data using a definition list as you’re relating both the action and the distance traveled. The distance traveled is a direct result of the action being taken so a definition list would work well.

<ol class="driving-directions">
  <li><dl><dt>Head southeast on Crossgates Mall Rd</dt>
    <dd>0.2 mi</dd></dl></li>
  <li><dl><dt>Turn left onto the Washington Ave Ext E ramp
    to I-90 Thruway/I-87</dt>
    <dd>407 ft</dd></dl></li>
  <li><dl><dt>Merge onto Washington Ave Ext</dt>
    <dd>0.9 mi</dd></dl></li>
  <li><dl><dt>Continue on Washington Ave</dt>
    <dd>3.9 mi</dd></dl></li>
  <li><dl><dt>Turn right at Robin St.</dt>
    <dd>417 ft</dd></dl></li>
</ol>

To me, using a combination of an ordered list as well as integrating a definition list results is a much more semantically rich set of driving directions.

A quick note about address

From time to time, I’ll come upon some markup that uses address incorrectly. address is defined as:

The address element may be used by authors to supply contact information for a document or a major part of a document such as a form. This element often appears at the beginning or end of a document.

Without reading the definition, I can understand why some people may assume that address is used to mark up a segment of data that represents any address, but in reality, it is used to distinguish how to contact those responsible for the document. It isn’t applicable to use the address tag to mark up the street address of each step here.

What about imagery in driving directions?

Many times, driving directions include images which help to classify what information each instruction is providing. There may be an arrow indicating which direction to turn, an interstate sign, or something like a traffic light to indicate a future encounter. How should these images be included? In my opinion, this is one of the times where semantic image use should be looked into. Taking a step back and thinking about it, these images are unique in that they aren’t part of the site design. They’re in place to convey pieces of information to the reader. Making the adjustments to our example:

<ol class="driving-directions">
  <li><dl>
    <dt>Head southeast on Crossgates Mall Rd</dt>
    <dd>0.2 mi</dd></dl></li>
  <li><dl>
    <dt><img src="images/turn-left.jpg" alt="Image signaling
    a left turn" />Turn left onto the Washington Ave Ext E ramp
    to I-90 Thruway/I-87</dt>
    <dd>407 ft</dd></dl></li>
  <li><dl>
    <dt>Merge onto Washington Ave Ext</dt>
    <dd>0.9 mi</dd></dl></li>
  <li><dl>
    <dt>Continue on Washington Ave</dt>
    <dd>3.9 mi</dd></dl></li>
  <li><dl>
    <dt><img src="images/turn-right.jpg" alt="Image signaling a
    right turn" />Turn right at Robin St.</dt>
    <dd>417 ft</dd></dl></li>
</ol>

Alternatively, it would be argued that the dt provides the instruction and the image is merely redundant. I think that is the decision of the developer, but I do feel it is more applicable to include these ‘helper’ images in this way as opposed to being a background-image to the dt. What do you think? Should an element be classed and provided a background-image as opposed to including the image inline? What other ideas do you have to improve the example?

Advertise here with BSA

There have been many pieces written on both graceful degradation as well as progressive enhancement. Some people feel that they’re one and the same, but personally I think they are very similar, but each have unique characteristics. While a document that gracefully degrades will transparently appear as normal to any reader, progressively enhancing the document adds layers of functionality, if available, after the fact.

Relating Progressive Enhancement to Your CSS

Many times when you read about progressive enhancement on the Web, the discussion revolves around JavaScript. The general idea is to provide unobtrusive JavaScript that will not interfere with the viewing of any document, regardless of browser capability. As Web based applications become more advanced, there are many visual features being included to [hopefully] benefit the reader.

What’s unfortunate is that it is becoming more common for designers to neglect progressive enhancement once unobtrusive JavaScript is obtained. There are countless JavaScript libraries available, full of code that is designed with progressive enhancement in mind. The issue that’s becoming increasingly problematic, in my opinion, is the associated style that is required to achieve desired visual effects.

If your document will be enhanced when a reader doesn’t have a JavaScript equipped Web browser, it’s equally important that your CSS doesn’t interfere. While JavaScript should only control document behavior, that behavior often involves making changes to the DOM that are in turn effected by the document style.

As an example, there are many times that designers will adjust the visibility or display of an element in their CSS for the sole purpose of toggling that property at some point. What’s important to keep in mind is that readers without a JavaScript enabled browser will apply the entire style sheet, but have no script available to execute that fancy Ajax animation.

Use JavaScript to Progressively Enhance your CSS

In my opinion, there’s nothing wrong with altering the visibility or display of certain elements to bring your Web application together. It’s important to keep in mind the necessity of retaining progressive enhancement with your CSS as well.

On a recent project I ran into a situation in which I wanted certain elements to have stylistic elements that required JavaScript for full functionality. It would have been a nice feature to add, but requiring JavaScript isn’t an option. I needed a way to separate a small bit of CSS which would only be applied if the reader were able to make use of the JavaScript provided with the document.

I was reminded of an article I had read some time ago (that I’m having trouble locating) which mentioned using JavaScript to manipulate the DOM and add your CSS. This way, the styles are only applied using the technology which will control other document behavior. What we’ll do is generate a link element, append the proper attributes, and finally insert our element into the document tree by placing a snippet in the head.

<script type="text/javascript">
  //<![CDATA[
    initStyles = document.createElement("link");
    initStyles.setAttribute("rel","stylesheet");
    initStyles.setAttribute("type","text/css");
    initStyles.setAttribute("media","screen,projection");
    initStyles.setAttribute("href","css/js-init.css");
    document.getElementsByTagName("head")[0].appendChild(initStyles);
  //]]>
</script>

This snippet allows us to include the CSS to ‘initialize’ the document in preparation for user interaction via JavaScript. The style will only be applied if your reader has a JavaScript enabled browser, making it extremely likely that your Web app JavaScript will operate as intended.

It’s not the only way

Appending a style sheet to your document using a method like this may not be ideal in your opinion. You could effectively use your existing CSS and manipulate the DOM in a way that doesn’t interfere at all with a JavaScript-less reader. I’m not a fan of using JavaScript to directly control the style of an element. To me, (something like) element.style.color = 'red' triggers nightmarish images of <FONT color="red">Lorem ipsum</FONT>. I try to stray away from using document behavior to control document style, that’s reserved for CSS.

What is truly important is ensuring your document is still equally usable whether you’re working with JavaScript or not. That goes beyond taking your scripts into consideration, any preparation you create with CSS must be monitored as well.

Advertise here with BSA

SciTE – My New Favorite Editor

SciTE is (freely) available for both Linux and Windows, but this article will dedicate itself to the Linux install process as it is the only environment in which I’ve set it up. Furthermore, the details of the installation process will be specific to Ubuntu 6.10, as it is my distribution of choice, but the install process itself should be similar on just about any version of Linux.

Installing SciTE

SciTE is easily available to install by executing the following in a terminal:

sudo apt-get install scite

After you enter your password, SciTE will be automatically installed and setup. You can also install SciTE using Synaptic Package Manager, but I prefer the command line. SciTE can be run by entering scite in the command line, or using the menu: Applications > Programming > SciTE Text Editor.

By default, SciTE doesn’t include the snippet functionality offered by TextMate, but incorporating all of the hard work by Mitchell, SciTE Snippets are easy to implement.

Implementing SciTE Snippets

I spent some time trying to grasp how to actually install the snippets plugin Mitchell developed. Following his documentation proved to be quite useful and I had SciTE Snippets up and running after a bit of trial and error. It involved a process that some people new to Linux may find intimidating, so I’ve decided I would try to use the SciTE binaries offered on the site. Not only do you get working Snippets, you’re provided with a new look and feel for SciTE itself. A large library of Snippets are included to work with and add upon and I found it to be a great starting point for using Snippets in SciTE.

The binaries Mitchell offers are stored on Google Code and available for Windows as well as Linux. Download the latest Linux Binaries (scite-tools_linux_bin_r3.tgz at the time of this writing) as well as the Source Code (scite-tools_src_r3.zip at the time of this writing) which will come in useful later.

Extract scite-tools_linux_bin_r3.tgz

tar xzvf scite-tools_linux_bin_r3.tgz

Copy the new SciTE binary over your installed version

cd scite-tools_linux_bin_r3
sudo mv /usr/bin/scite /usr/bin/scite.bak
sudo cp SciTE /usr/bin/scite

The binary has now been copied to your existing installation, it’s an updated version compared to the one offered in the Ubuntu repositories. You’ll notice that if you run SciTE, not much has changed; we’ll still need to copy over Mitchell’s configuration files as well as his included snippets.

Extract scite-tools_src_r3.zip:

unzip scite-tools_src_r3.zip

Implement configuration and Snippets:

cd scite-tools_src_r3/
sudo cp -R * /usr/share/scite/

Just to be clear, not only have you copied over the configuration and included Snippets, you’ve also copied the source. If you feel the need to remove the extra files, feel free to do so. Now that the configuration files have been copied, you can run SciTE again, and you’ll see it’s received quite a makeover:

SciTE Snippets are now at your disposal using the CTRL+i keyboard combination after typing your trigger.

Customizing SciTE Snippets

While Mitchell includes many of his personal Snippets, I have a certain way of writing markup, style, and code. Each developer will want to make adjustments to existing snippets — as well as add some — in order to streamline his process even further and take full advantage of their presence. Managing your Snippets is actually quite easy if you follow the conventions established by Mitchell. Your snippets are stored in /usr/share/scite/scripts/ and organized according to language.

Creating Snippets is well documented on Mitchell’s site, and he even offers a Ruby Snippet Generation Script which can come in quite handy. Personally, I found the example Snippets offered in /usr/share/scite/scripts/html/snippets.lua to be most helpful in understanding Snippets and how they worked. I simply manage the snippets I wish to use in that file and it’s worked out well so far.

Mitchell has provided a really great tool for many people, free of charge. He has provided screencasts which show his Snippets in action, including a demonstration of how to use scopes, a very powerful feature he’s included.

Customizing the SciTE interface

When using SciTE for the first time, I was surprised not to find a Preferences dialog. Like anybody, I have preferences as to the type used in my editor, so I was looking to make that simple change. Instead of a Preferences dialog, you’ll need to edit a configuration file. While I’d much prefer to have a GUI dialog, having to edit a configuration file really isn’t that big of a deal to me, but I know many people would look at the application as inferior for that very reason.

Regardless, the configuration file can be edited by selecting Options > Open Global Options File within SciTE. The associated file holds all of the preferences you’ll want to tinker with to get SciTE to look just how you want it. If you’re using Mitchell’s configuration, you’ll notice he took the time to reorganize this file, making it very easy to manage.

SciTE (especially with Snippets) is my new favorite tool

I’ve found that creating Snippets can be a lengthy process, but one that offers great benefit. Using Snippets allows you to work at a much faster pace without getting ahead of yourself and losing focus. It takes away much of the tedious aspects that come with writing markup. The speed benefits alone made switching from Bluefish/Quanta worth it. I have a feeling that many editors will incorporate such a feature in their upcoming releases.

It goes without saying that SciTE has all of the features you would expect in an editor: line numbering, code folding, syntax highlighting, etc. I’m very pleased to make the switch to SciTE, and I definitely recommend it to anybody who isn’t willing to fork over the cash for a copy of E. I’ve only been working with SciTE a short time so far, so if anybody has any tips or tricks they’re willing to offer, it would be great to post them as a comment.

Advertise here with BSA

Suckerfish HoverLightbox Redux Demo

The Redux has a number of improvements, mostly visual, but some behavioral changes as well. Before going into detail, it’s important to give due credit to those who helped make the Suckerfish HoverLightbox a possibility.

Suckerfish Dropdowns are widely accepted and used by many developers in order to include a more comprehensive navigation in their various designs. Patrick Griffiths and Dan Webb changed a lot when they published their article to A List Apart. The Hoverbox Image Gallery by Nathan Smith is a great technique that I’ve found myself using time and time again in various otherwise plain image gallerys. Finally Lightbox JS by Lokesh Dhakar is used to bring the images into full view. Each of these pieces have been slightly modified for use in the Suckerfish HoverLightbox, but each deserves the utmost respect for their hard work and ingenuity.

Suckerfish HoverLightbox Redux (.zip)

The provided download includes a ZIP archive consisting of the vanilla Suckerfish HoverLightbox demo and all the necessary JavaScript, CSS, XHTML, and images.

Modifications that were made

When I began work on the Suckerfish HoverLightbox, I started from the inside out. I began with Lightbox JS 2.02 as it is an upgraded version from the first, which the original Suckerfish HoverLightbox employed. This version allows someone to navigate through each set of pictures while continuing to use the Lighbox, as opposed to closing it out each and every time. I like that feature, as it can save me time when flipping through a collection of pictures.

In my personal experience, some people have had difficulty realizing that navigating from picture to picture was possible. Unless it was explained, people would continue to close Lightbox and click another image in the series. After being shown that mousing over the picture will bring up some options, the ‘local’ navigation would be used. To make things easier, I added in another set of navigation elements to the Lightbox. Near the Close button, there is now a set of small arrows available when there are more images to browse in a particular set. It seems to have helped some people, while others who have had prior experience with Lightbox can continue to use the native local navigation.

The Hoverbox Image Gallery was not modified very much beyond a few color changes and dimension adjustments. The technique is quite robust and does what it aims to do very effectively. It’s quite easy to apply to almost anything, and the Suckerfish HoverLightbox is no different.

Finally, some changes needed to be made in the JavaScript for the Suckerfish Dropdowns. Originally, the script used the DOM to find a specific element with a particular id. This was changed to find the ‘gallery’ container and work from that point. There was also JavaScript added to assist with a nasty IE6 rendering bug I came across when putting the demo together.

Problems I ran into

Naturally, I ran into a snag here and there when putting the Redux together. I wanted this version to be cleaner and appear more organized. The design of the first version was severely lacking and in my personal opinion, the Redux is a step forward. While the last version was easier to customize, this version only requires a couple image changes, and some color updates in the CSS.

The only major roadblock I ran into was when testing in Internet Explorer 6. The nested unordered lists weren’t displaying correctly due to the fact that percentages were used for widths in order to make the Redux easier to work with. After determining the cause of the issue, the example was modified and the rendering was corrected.

What would you change?

As with the first version, I’m pleased with this version and feel it came out as well. The Redux degrades gracefully (assuming worthy alt attributes are used). After the original Suckerfish HoverLightbox was published, a few people suggested that the gallery was a bit invasive in that it appeared on rollover using CSS. I took that into serious consideration when putting together the Redux, but elected to stay away from including more JavaScript. To a degree, I do believe that the Redux is still a bit invasive in that it is very likely a reader will unintentionally roll over the gallery. Do you think it’s better or worse that the Redux displays the images on rollover? Should a version including JavaScript to toggle displays be put together?

I look forward to hearing any reactions to the Redux, in hopes of improving the example even further in the future.

Advertise here with BSA

The Problems with Image Replacement

As you may know, image replacement can be a touchy subject. Your aim should be to develop something that is equally usable by each and every person that finds their way to a site you designed and/or developed. Including extra markup that isn’t semantic didn’t seem like a path I wanted to travel, so many of the “accepted” image replacement techniques were put aside. The remaining choices left little to be desired if your reader happened to be viewing a site with images disabled and CSS enabled.

“Who does that?” you may ask. If I were to take a guess, it could be someone who is fairly Web-savvy and has the ability to use their browser in that particular fashion because they’re at a relatives house and stuck on a choking dial-up connection. That’s just one of the possibilities, and I’m sure if we all put a few minutes into thinking about it, we could think of another situation in which we wanted to simply disable images only and get straight to the content.

An Idea was Born

As I thought about it, I went in a direction that others have gone before, in that the actual text wasn’t removed from display all together, it was merely camouflaged with the background. I stuck with that technique because removing the words from display as step one doesn’t let you get much further with images disabled.

The trouble with camouflaging the text is that most of the time, disabling images simply leaves the ‘invisible’ text on screen. The text proves to be useless to a reader unless they disable CSS as well. There had to be a better way.

And That’s When it Came to Me

It was at that point I began testing with a structured block element by giving a heading a specific height and width. I gave that element a background-color that contrasted with the color in order to make the text visible again. Once that was complete, everything else seemed to fall into place.

Since I had a block element with a height and width, I was able to cut out my desired image for replacement, and simply include it as the headings background-image. A crucial step, however, is to leave yourself enough real estate to work with when cutting out the image. What I mean by that is cutting out an extra couple dozen pixels at the top of the image, because that is where your text will reside. The next step is to give the heading a color that matches the background color of the site (in order for the text to camouflage). The last step is simply shrinking the font-size of the heading so that our content resides in the real estate we set aside.

To provide a visual example, here’s what results:

You can recreate just that on any of the image based headings around the site. If you disable images, the black background appears and the text is now visible, albeit small. Go ahead and bump the font size up a couple notches, the technique survives it for a bit. I don’t think that many readers would feel the need to bump font size three or four levels, do you?

Obvious Limitations to the Technique

As with almost everything, there are certain limitations to using a technique such as this. First and foremost, it won’t really work with anything but a solid color background. Secondly, if a user were to increase their font size a few jumps, your text will begin to overlap the images you created and look like quite a big mess. Lastly, first time (and some repeat) readers will see that stark background color you gave your heading and it may take them by surprise. Once your CSS and images are cached the problem shouldn’t continue, but some people browse with their cache completely disabled. Something like this might prove to be annoying to readers such as those.

Another thing that could be considered a limitation is the extra space you have to leave at the top of every heading. Again, this was something that just fell into place with my design, I wanted the extra margin there as it was. This method of image replacement won’t be the end all for other techniques; it just seemed to fit my goal set quite nicely.

How do you Feel About the Technique?

So far, I’ve had some mixed reactions to the technique. Some people think it’s semantic and innovative while others don’t like the fact that the background color appears. I can definitely see both sides, but I feel the semantic benefit of not including empty <span>s outweighs it in a way.

Find this useful? Digg it.

Advertise here with BSA

One of the major drawbacks to RSS is that its use hasn’t quite filtered down to your average user quite yet. RSS might sound familiar, but knowing what it can be used for is less common. More often than not, when informing a client that we’ve equipped their new site with an RSS feed, my coworkers and I are presented with a look that expresses nothing but confusion. Upon explaining what RSS is and the existing uses for the technology, the client still seems perplexed — almost as if to say “So what?”

Given the wide range of exposure surrounding RSS, I think it’s really important to handle your feed in a way that will be usable by as many people as possible. One way to accomplish that is to apply a bit of structure and style to your feed in case an inexperienced user were to somehow find their way to your RSS via their browser.

Applying CSS to your RSS

It is possible to include a Cascading Style Sheet in the definition of your RSS feed using the following code snippet:

<?xml-stylesheet type="text/css" href="rss.css"?>

This line of code can be inserted just under the XML version declaration and the CSS will be applied to your document. You can design the display of your style sheet in any way you please, using the XML tags provided in your feed. Customization can become quite extensive using this method, and you can make great strides by applying a bit of CSS to your RSS. Now when someone new to RSS decides to click on your Feed Icon, they won’t be faced with a document that looks like a foreign language. A problem I have with this method, however, is that the user will be no more educated about RSS than they were before. They still won’t know what they’re looking at, or the primary reason for it’s existence. There is a better way.

I have read articles describing a few ways to add a bit more information to a feed that has been styled using CSS. One suggestion was to add a few comments at the top of the file describing the purpose of the document and telling the user they’re viewing an RSS feed. I wasn’t too pleased with this solution because it basically degrades the decent style you had going for you to begin with. Luckily, there’s more you can do.

Styling Your RSS with XSL and CSS

By default, when navigating to any particular feed, you’re shown the raw markup of the document (depending on browser and RSS version). Sometimes you’re not even shown the markup, but the actual copy of the content — unformatted and unstructured. It should be known that the result varies among each version of RSS and browser. Displaying source code or a document tree isn’t completely beneficial to a novice end user, no matter how you look at it.

Ideally, we would be able to use the content of our feed along with a predefined structure to introduce a viewer to RSS. Given the power of XSL, you can do exactly that.

What is XSL?

XSL stands for Extensible Stylesheet Language, and it can be defined using the first few lines from the W3C’s About XSL page:

XSL is a language for expressing style sheets. An XSL style sheet is, like with CSS, a file that describes how to display an XML document of a given type. XSL shares the functionality and is compatible with CSS2 (although it uses a different syntax).

To make a long story short, XSL gives us the ability to restructure our feed should it be viewed in a browser via the location bar. I highly suggest snooping around the W3 spec of XSL along with the XSLT 1.0 Spec to really understand the inner workings of styling your RSS feed.

Using XSLT in Conjunction with RSS

In my opinion, if a user were to view my feed in a browser, it would be great to have an effectively styled document containing not only the information from the feed, but also a small explanation of the document. You don’t want people to be using your feed by typing it into their browser do you? If a novice user is faced with a styled RSS feed, they might be likely to do just that, all the while missing out on the true potential of RSS.

Take for example, the RSS feed of Monday By Noon. Using a few select pieces of XSLT, we can accomplish something just like that. I think it’s nice that an unknowing user will be faced with an explanation of what it is they’re viewing before they start reading the actual content of my feed. Hopefully it will give them a good starting point into discovering RSS and determining if it’s something they’re interested in.

How to Apply XSLT to your RSS Feed

To apply XSLT to your feed, you only have to perform a few steps. First and foremost you must make an addition to your RSS. Adding the following line of markup will tell the browser where to find your XSL file:

<?xml-stylesheet href="rss.xsl" type="text/xsl" media="screen"?>

That is the only modification you’ll need to make in that file. From there, you will need to create your XSL file, in this case, rss.xsl. It is at this point you begin to have some creative freedom. It’s important to keep in mind that you don’t want to go overboard and include an exact iteration of your site. After all, you want the user to know that the document they’re viewing isn’t meant to be viewed in a browser, right?

Here is an example of the XSL being used on this site:

<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
  <head>
    <title><xsl:value-of select="rss/channel/title"/> RSS Feed</title>
    <style type="text/css">
    @import url(rss.css);
    </style>
  </head>
  <body>
    <div id="explanation">
      <h1>Monday By Noon RSS Feed</h1>
      <p>You are viewing an <acronym title="Really Simple Syndication">RSS</acronym> feed.  An RSS feed is a file
      allowing users a way to read updates to a website either through a third party RSS aggregator or other form of RSS
      syndication service.  You can find out more about the RSS file format at the
      <a href="http://en.wikipedia.org/wiki/RSS_(file_format)">Wikipedia RSS entry</a>.</p>
      <p>You may use the <acronym title="Uniform Resource Locater">URL</acronym> of this document for any RSS purposes.</p>
    </div>
    <div id="content">
      <xsl:for-each select="rss/channel/item">
      <div class="article">
        <h2><a href="{link}" rel="bookmark"><xsl:value-of select="title"/></a></h2>
        <xsl:value-of select="description"/>
      </div>
      </xsl:for-each>
    </div>
  </body>
</html>
</xsl:template>
</xsl:stylesheet>

As with any markup language, it is very important that proper usage be researched. I’m going to go over some of the basics of the file above, but if you plan on implementing something like this, take a look at the W3C XSLT 1.0 spec.

Two of the most useful pieces of XSLT that are put into use above are xsl:value-of and xsl:for-each. After taking a quick look at their usage, xsl:value-of allows us to pull data directly from the RSS feed, and using xsl:for-each allows us to ‘loop’ through each of the items stored in our feed. This allows us to format our data in a way we can effectively style for proper presentation to our reader.

Besides the ability to insert structural markup in our new document, XSLT also gives us the power to properly mark up a section of the document that explains the purpose of the file and gives the reader an outlet to find out more about the technology. All this is possible while retaining the look and feel of our site in an effort not to scare our user.

As you can see, CSS is applied to the document using @import url(rss.css);. If you take a look at the style, you can see it is short and to the point:

* { margin:0; padding:0; }

html { display:block; background-color:#960000; padding-bottom:50px; }
body { font:80% Verdana, sans-serif; color:#000; background:#fff url(pagebg_rss.jpg) top left no-repeat; padding:25px 0 0 35px; }

a { color:#960000; }
a:hover { text-decoration:none; }

h2 { font-weight:normal; border-bottom:1px solid #960000; margin-bottom:0.4em; }
h2 a { display:block; margin-bottom:0.2em; text-decoration:none; color:#000; }

div { line-height:1.6em; }

div#content { background:#fff url(logo.jpg) bottom right no-repeat; margin-right:15px; padding:1em 0 55px 0; }
div#content div { margin:0 1em 1em 0; }

div#explanation { padding:1em 1em 0 1em; border:1px solid #ddd; background:#efefef; margin-right:2em; }
div#explanation h1 { font-weight:normal; font-size:1.8em; margin-bottom:0.3em; }
div#explanation p { margin-bottom:1em; }

This CSS is applied just as it would be to a HTML document. You can go into as much or as little detail as you’d like when customizing the output of your XSLT, but in my opinion the document should retain the brand and remain minimal. It should include an area of information surrounding RSS, and help the user have a proper exposure to it.

Why not Just Use FeedBurner?

FeedBurner has become quite a popular service for many sites offering RSS. Using FeedBurner, you’re able to view certain statistics about your feed not otherwise available (such as how many readers you have). Lots of people love statistics, so FeedBurner is the perfect way to get another stat not otherwise available to them. If you have ever clicked on a FeedBurner link as opposed to copying the URL for other use, you’ll notice that you end up at a FeedBurner branded page using XSLT. The page includes all of the latest updates related to the site you came from, along with information about FeedBurner. While this is a decent result for the site owner, it’s nothing short of excellent for FeedBurner in terms of free advertisement.

Using a custom blend of XSLT and CSS you’re able to retain your brand in an attempt not to confuse your reader. This may not outweigh the ability to track the statistics of your feed, and FeedBurner might be too great to pass up. I don’t have extensive experience with FeedBurner, but from what I can tell, the markup of your posts is included in the browser rendered version, which also may be a drawback. Again, this may not be a big deal to you — as with many things, it comes down to audience, circumstance, and personal preference.

Don’t Browsers Apply Default Style to Feeds?

While it’s true that some browser publishers have thought ahead and included the ability to apply a default style sheet and structure to various feeds, this also runs into the same issue as FeedBurner in that your branding is lost. What’s good is that when the browser notices you’ve done custom work to style your feed, your markup and CSS is given precedence over the browser default. While I think the idea of applying a default browser style is better than nothing, with a little effort you can have a far better result.

Is this a Solution for You?

Using XSLT and CSS to customize the display of your feed may or may not be something you’re interested in. From what I can see, many people may not think there is much purpose to adding such functionality simply because it won’t be used. My personal experience, however, tells me differently. If nothing else, using this technique will help expose RSS to the those who have never heard of it before. This method also provides an effective solution for those who don’t care about RSS and don’t want to know what it is or what it’s for, but at the same time they don’t want a link on their page directing people to a document tree.

Help spread the word: Digg this article

Advertise here with BSA

MBN DuoTone Headings Demo

If you were to take a close look at the example heading in a browser supporting both JavaScript and CSS, not only would you realize it’s actually comprised of two colors, you would see that it isn’t using any images to create the effect. Further inspection would show you that the following code was used to insert the heading:

<h2 class="monday">To Make an Example</h2>

So what is creating the heading above? To put it simply; that line of HTML, a bit of CSS, and some manipulation of the DOM using JavaScript.

How does it work?

One of the major benefits to DOM scripting is the fact that it will degrade gracefully and allow a user without JavaScript the ability to continue proper use of the document he or she is viewing. When it comes to the MBN DuoTone Headings, a user without a JavaScript compatible browser isn’t going to know they’re missing out on a two colored heading. As stated above, this technique is purely for the visual enhancement of the average browsing experience.

If you’re able to see the DuoTone Heading above, it means that a script was able to scan through the markup of this document looking for headings given a certain class. The script searches for the class because when it comes to headings, a designer or developer will often want to use the same style repeatedly. Using the id would restrict use of the effect. When the script finds any heading with this particular class, duplicates the original content with an additional span. This change is made by manipulating the DOM, so those viewers who are browsing without JavaScript support will only see the original heading markup. This is ideal because if the additional markup was present no matter what, viewers without JavaScript would see duplicate content for each header which would be very confusing.

Once the script has run its course, the style sheet is applied to the document and you are left with MBN DuoTone Headings. A lot can be done with this technique as far as the CSS is concerned. You can see a few other implementations by looking at the MBN DuoTone Headings Example Page.

Under the Hood

To implement MBN DuoTone Headings, a small piece of JavaScript will be needed. The first challenge was to insert a function that would locate each instance of a certain class within the markup. Basic DOM scripting provides a method to find an instance of an element based on its id, but not by its class. Luckily, Dustin Diaz, JavaScript connoisseur that he is, had written getElementsByClass and Jonathan Snook had written one too. Thanks to the function and a slight modification, we have the location of each heading with a class of “monday” using the following code:

/* Credit Where Credit is Due

getElementsByClass Written By: Dustin Diaz

http://www.dustindiaz.com/getelementsbyclass/

Slight minor modification by: Jon Christopher
      http://www.MondayByNoon.com                   */

function getElementsByClass(node,searchClass,tag) {
    var classElements = new Array();
    var els = node.getElementsByTagName(tag); // use "*" for all elements
    var elsLen = els.length;
    var pattern = new RegExp("\\b"+searchClass+"\\b");
    for (i = 0, j = 0; i < elsLen; i++) {
         if ( pattern.test(els[i].className) ) {
             classElements[j] = els[i];
             j++;
         }
    }
    return classElements;
}

function showSpans() {
if(document.getElementsByTagName && document.createElement){
    for (var l=1;l<=6;l++){
    var headingArray = getElementsByClass(document,'monday','h'+l);
        for ( var i=0, len=headingArray.length; i<len; ++i ){
             var heading = headingArray[i];
                 var hString = headingArray[i].firstChild.nodeValue;
                 var span = document.createElement('span');
                 heading.appendChild(span);
                 span.innerHTML = hString;
        }
    }
    }
}

window.onload=showSpans;

This particular piece of JavaScript is using window.onload so if you plan on implementing MBN DuoTone Headings on your own site, make sure it won't be interfering with other scripts you may have running.

The script will loop through every heading found and insert a span just after the heading content. Within the span, a duplicate copy of the content is inserted. That's the only purpose this script serves and it's all we need it to do, the rest is up to the CSS.

The Style Sheet

Giving any heading level a class of "monday" in the original markup will trigger the effect. As stated before, a span with duplicate content is inserted next to the original heading content. The following styles are then applied:

.monday {
    color:#369;
    position:relative; }

.monday span {
    color:#497eb2;
    height:0.55em;
    display:block;
    position:absolute;
    top:0; left:0;
    overflow:hidden; }

The heading itself is given a position:relative which acts as a reference point for the span. The span is styled with position:absolute, positioned to the top left of the heading and given a height of 0.55em. Using em will render as half of the parent elements font size, which is essential for the technique. Setting display:block and overflow:hidden allows us to cut the span in height to create the DuoTone effect. Setting a different color to the span and its parent heading finishes the technique.

There are more effects you can generate by changing up the CSS a bit, some of which you can see on the MBN DuoTone Headings Example Page. You can download a zipped version of the example page below:

Download MBN DuoTone Headings

Hasn't this Been Done Already?

At the time of thinking up the idea for developing this script into something useful, I wasn't aware that Stu Nicholls had beat me to the punch by quite some time and showed off his own technique for two-color headings. While disappointed I wasn't the first to come up with the idea, I felt it was still a worthy subject to touch upon. Unfortunately, Stu Nicholls' two color headings reduce to a one color heading in Internet Explorer 6 using the star hack. My testing so far has shown me that MBN DuoTone Headings render correctly in IE6. I have also tested in Firefox, Opera and Safari and things seem to render correctly. If anybody finds otherwise, please post your findings below.

Semantics of this Technique

As always, semantics come first when it comes to enhanced effects using JavaScript, CSS, or any other technology. As I had stated above, the semantics in this example weren't compromised. Manipulating the DOM allows us to only insert the extra markup if support is available. One pitfall to the technique would be if the user had JavaScript support, but no support for CSS. Although uncommon, it is a certain possibility and should be taken into account.

If you were to browse this example page using a text based browser such as Lynx you're faced with the following:

The extra markup is not included if support isn't present. A user viewing your document with a screen reader isn't going to have to deal with hearing each heading twice before moving on and you would be faced with the same result had you been navigating the document without JavaScript support.

Advertise here with BSA

From time to time I come across some truly impressive techniques that are a great blend of CSS, XHTML, and sometimes JavaScript. Personally, I am not a big fan of implementing JavaScript, but it is sometimes unavoidable. That is usually due to circumstances created by certain browsers that will remain named: Internet Explorer. I was truly impressed by the development of the Hoverbox Image Gallery written by Nathan Smith of SonSpring. It was great to come across some optimization of the code by Craig Erskine and I thought it was a really creative way to show a collection of images in a gallery. After starting a project with a colleague, I was struck with an idea. How would it look to blend this technique with a set of Suckerfish Dropdowns originally published by A List Apart (and revised)? Take a look for yourself:

Suckerfish HoverLightbox Demo

My initial reaction was that I thought it looked pretty neat and would be a nice way to present sets of images. It then occured to me that it might be nice to include Lightbox JS written by Lokesh Dhakar in the mix. Putting these techniques written by these great developers together resulted in quite an expandable image gallery.

How it was Done

Being that Suckerfish, Hoverbox, and Lighbox were all written in an organized and straightforward fashion, combining them was fairly simple. I left the JavaScript files controlling the Suckerfish and Lightbox separate for organizational sake, and also used a separate stylesheet to control the Suckerfish and Lightbox style. Being that all three techniques were developed to work cross browser, only minimal edits were required in the CSS to have the gallery behave how I wanted.

Semantics of the Markup

What we’re faced with here is a nested unordered list containing two levels. The first level contains the gallery ‘names’ if you will, and the second level contains the image thumbnails. Semantically speaking, I think this markup is quite good. After all, at the most basic level the only thing we’re dealing with is a list of images. All markup is standardized and includes alt and title attributes.

Usability and Accessibility

A primary concern of mine is always the usability and accessibility of any given markup. An object of a Web developer should always be to aim towards achieving maximum usability and accessibility of all their work. A major usability issue that came up with the design of the Suckerfish HoverLightbox is inadvertantly hovering a top level list item which puts the contained thumbnails on display. If the user doesn’t mean to view the thumbnails, they can be quite invasive. One way to help this out is to provide enough real estate for your gallery so that if a user were to accidentally roll over a gallery heading, your content would not be hidden.

Javascript Degradability

One of my major issues with the inclusion of JavaScript is complete inoperability if I happen to have JavaScript disabled at the time. If JavaScript can not degrade, I think a new solution should be looked into. The JavaScript in Suckerfish HoverLightbox controls the thumbnail display in Internet Explorer since it does not support psuedo :hover elements. It also controls the entire Lightbox portion of the example.

If you were to view the example without a JavaScript enabled browser (excluding Internet Explorer), you wouldn’t notice a difference until clicking the image for the Lightbox. Instead you are linked to the full resolution image, which makes sense given the circumstances. If you happened to be viewing the example using a JavaScript disabled Internet Explorer, you would not be able to view the thumbnail galleries. Instead you would only see the gallery headings, which would be a link to either a static page containing your thumbnails, or possibly to the directory in which your full resolution images are stored. Given either situation, the example is less visually appealing, but still usable.

Using a Text Browser

There are definately people browsing the Web with text-based browsers. Albeit a very small percentage, they’re still out there and developers should meet their needs. Being that Suckerfish HoverLightbox is simply a two level nested unordered list, text-only output is very clean and organized. The top level list items contain links to another page, and the second level contains links to images which can be downloaded by a text-based browser such as Lynx.

Please excuse the small viewport, it is merely an example of what you would see had you been viewing this article (specifically the Suckerfish HoverLightbox example) using Lynx.

Results on a Screen Reader

When viewing this example using a screen reader, you will be faced with a very similar situation. Given the circumstances of the example, that it is an image gallery, it is quite useless to someone viewing with a screen reader. The point to take home here is that even if someone is viewing the example with a screen reader, they aren’t confused as to what you’re trying to get across.

If you are curious to see what a particular Web page renders as when using a screen reader, Fangs is a Firefox extension that emulates a screen reader. It can be very helpful when evaluating the accessibility of your Web site. Due to the semantic markup, you’re faced with a pretty self explanatory situation — a list of galleries which hold a nested list of images.

Examples

I realize that an example tailored to the design of Monday By Noon is not very useful to the end user, so I have compiled a couple of vanilla examples for examination and download. This example is very new to me and I encourage criticism and critique so that it can be refined to the most optimal end package for future use.

Download Suckerfish HoverLightbox

Vanilla Horizontal Example

I have included a horizontal example of Suckerfish HoverLightbox within this article, but there is also a vanilla horizontal version. I left it as basic as possible but also included some ‘before’ and ‘after’ text to mimic any given situation. Minimal styles were included and the markup was not modified.

Limitations of the Design

First and foremost, the biggest limitation to the horizontal design is the problems you run into when you have more than a few gallery headings. In this example, all gallery headings must be on one level because breaking into two levels would adversely affect the thumbnail views. This is really the only major drawback to the horizontal design and can be tackled using a vertical version.

Vanilla Vertical Example

I originally worked on a vertical example of Suckerfish HoverLightbox because that is the situation in which it would be applicable to the project I was going over with my colleague. In this example you can include a virtually limitless amount of galleries; however, I chose to include a horizontal version in this article because it seemed to fit better.

Limitations of the Design

At first glance, the drawback to this design is the amount of whitespace left behind. Depending on the design, this can work to your disadvantage, especially when there is a large number of galleries. When developing this example, I ran into a number of problems. Initially I wanted all thumbnail views to display in the same position, which would result in a more consistent experience. I quickly ran into problems when the top level list containing the gallery titles was taller than the thumbnail view itself. For example if there was a list of 10 different galleries and the 9th gallery had only one thumbnail. When this situation arose, I was unable to successfully hover the bottom gallery title, and actually use of the thumbnail to get to the Lightbox. The thumbnail would dissapear as soon as I left the gallery title on the left. This was due to leaving the :hover state of the gallery title anchor before hovering the nested list, resulting in the thumbnail view returning to a position of left:-999px; before we are able to make use of it.

I think the best way to illustrate the problem is visually:

The outlines delegate the border of the unordered list containing the thumbnail images. The red outline illustrates the height problem. In order for the Suckerfish to work, the mouse needs to travel from point (a) which is its current position, to point (b) which is within the red boundary. I first tackled this by setting the height of the container unordered list to auto, and then setting the height of the contained list to 100%. After testing in Firefox I was pleased with the solution (left hand blue outline). Unfortunately, Internet Explorer 6 did not render the lists height as 100% and therefore this was not an effective solution (right hand blue outline). The solution I chose was to position of the contained unordered list at the same height of the associated list item (the gallery title) which solved this problem. As a result, the thumbnail views are set to appear at the same height as the gallery heading to ensure usability, even if there is only one thumbnail present.

Finishing Thoughts

Overall, I feel that this is an effective way of presenting an image gallery using mostly CSS and only a small bit of JavaScript. I do feel that it is really only an effective solution for a small to medium sized image gallery because of the design limitations. It degrades well, is semantic, usable, accessible, and nice to look at. I hope that other developers take a look at this example and write about any changes they would personally make.

Although Suckerfish, Hoverbox and Lightbox have been extensively tested for cross-browser compatibility, I was able to test on PC in Firefox 1.5.0.1, Internet Explorer 6, Internet Explorer 7 Beta 2, Netscape 8 and Opera 8.53. On the Linux side I tested Firefox 1.5.0.1, Konqueror 3.4.3, Galeon 1.3.21, Mozilla 1.7.12, and Epiphany 1.8.2. I was unable to perform any testing on the Mac platform, but will do so as soon as possible.

Digg this Article

Advertise here with BSA