Parallax what?

Even if you’re not familiar with the term “parallax scrolling” you will certainly be familiar with the technique. Parallax scrolling is a 2d animation process that creates an illusion of depth by animating foreground layers faster than background layers. When you observe the landscape from a moving car, objects closer to the car appear to pass you faster than scenery further away. Parallax scrolling uses the same principle to trick the viewer into thinking they are observing a 3d scene.

Demo and Download

My demo web page shows one approach to building a vertical parallax scrolling interface:

View demo
Download source

You can scroll in the usual fashion, use the navigation menu at the right-hand side of the page, or the next/prev buttons that appear underneath each article. As you scroll, the page’s four content layers are animated independently of one another to create an illusion of depth.

The scrolling looks smoothest in Safari (at least that’s the case on my PC), but my demo should work in any modern browser.

Disclaimer 1: Because this is just an experiment I’ve not spent any time optimising the demo to work on mobile devices. I wanted to keep the demo lean ‘n’ mean, and not clutter it by sniffing mobile browsers and forking my code. On a production site you’d want to ensure that the site degrades gracefully on mobile devices, where scroll events and fixed positioning might work in unexpected ways.

Disclaimer 2: The navigation menu in my demo is inspired by the menu on the Nike Better World website. If you plan on implementing a similar menu on a production site, please be aware of its origin.

How it works

The articles and background layers are given a fixed positioned with CSS, and assigned a z-index so that the foreground layers appear above the background layers. The four layers are: small clouds, large clouds, balloon/landscape images, articles.

/* foreground (ballons/landscape) */
#parallax-bg3 {
    z-index: 3;
    position: fixed;
    left: 50%; /* align left edge with center of viewport */
    top: 0;
    width: 940px;
    margin-left: -470px; /* move left by half element's width */
}

Within each layer individual content elements are absolutely positioned. This was the most fiddly part of the process, since the elements need to positioned in such a way that they align in a pleasing manner when the user scrolls to any of the four articles. In this case it was really just a process of trial and error.

#bg3-1 {
    position: absolute;
    top: -111px;
    left: 355px;
}
#bg3-2 {
    position: absolute;
    top: 812px;
    left: 321px;
}
/* etc... */

A few lines of jQuery control the parallax effect, triggered by a scroll event. I was surprised how easy this was to achieve, it is literally just a handful of lines of code.

$(window).bind('scroll',function(e){
    parallaxScroll();
});
 
function parallaxScroll(){
    var scrolled = $(window).scrollTop();
    $('#parallax-bg1').css('top',(0-(scrolled*.25))+'px');
    $('#parallax-bg2').css('top',(0-(scrolled*.5))+'px');
    $('#parallax-bg3').css('top',(0-(scrolled*.75))+'px');
}

As you can see the CSS top property is used to move each layer as the user scrolls. The foreground layer is always aligned to the top of the document, while the movement of other layers is adjusted according to their depth. The lower a layer sits in the stack, the less distance it is moved.

The rest of the jQuery is concerned with controlling the navigation menus. When the user clicks a navigation button the page scrolls to the top of the associated article. In the event that the user has JavaScript disabled, regular HTML anchor links still allow the page to be navigated, but without any fancy pants animations.

Next steps

I’m sure there are plenty of other approaches to parallax scrolling, and hopefully my experiment provides a starting point for your own explorations of the technique.

Update

I have updated the demo so that each parallax layer is given a fixed, rather than absolute, position. This approach gives a smoother scrolling effect.

• Better handling of checkbox results in the emailResults method.
• A custom form submit URL can be passed to the FormBuilder constructor. Useful when using FormBuilder in an environment that is performing URL rewriting.
• Replaced deprecated ergei functions with preg_match.
• Checkbox field types are correctly processed when field is not mandatory, and the user didn’t check any of the available options.
• Added new field type: file (for file uploads). Note that files are currently not emailed when using the emailResults method. Any handling of the uploaded files should be accomplished manually by accessing PHP’s $_Files array.
• The textbox and textarea field types now accept an optional defaultvalue parameter.
• Fixed a bug that meant checkboxes had a CSS class of ‘fbheckbox’ instead of ‘fbcheckbox’.

If you encounter any problems with the new version please let me know.

PHP example:

HTML example:

CSS example:

JavaScript example:

I’m not sure who designed the Monokai theme originally, but it has cropped up in Textmate, Notepad++, Sublime – where it is the default colour scheme – and no doubt a bunch of other editors as well.

My version of Monokai is based on a Notepad++ theme, but I have standardised the color of variables (green) and symbols (white) across all the languages.

I don’t actually use phpDesigner much these days – I’ve jumped ship for Aptana Studio 3 – but I still think it is a great code editor, and hopefully someone out there will get some use from my theme.

Download

Download Monokai theme for phpDesigner

Installation and uninstallation instructions are included with the theme. The theme has syntax highlighting colors for the four languages I work with: HTML, CSS, JavaScript and PHP.

Important

There is currently a bug in phpDesigner that sometimes causes the ‘separator’ colors to revert to their defaults (e.g. the color of tags reverts to black). The only sure-fire way to get things back to normal is to open the phpDesigner preferences dialog, and click ‘OK’.

Apparently this bug will be fixed in the next release of phpDesigner (yay!).

• Tweets are cached to avoid exceeding Twitter’s limit of 150 requests for a user’s RSS feed per hour
• A fallback is provided in case the twitter feed fails to load
• Replies (tweets beginning with @) can optionally be ignored
• A configuration parameter allows you to specify how many tweets are displayed
• Dates can optionally be displayed in “Twitter style”, e.g. “12 minutes ago”
• You can edit the HTML that wraps your tweets, tweet status and meta information
• The username which prepends each tweet in Twitter RSS feeds is automatically stripped

<?php
 
/**
 * TWITTER FEED PARSER
 * 
 * @version	1.1.1
 * @author	Jonathan Nicol
 * @link	http://f6design.com/journal/2010/10/07/display-recent-twitter-tweets-using-php/
 * 
 * Notes:
 * We employ caching because Twitter only allows their RSS feeds to be accesssed 150
 * times an hour per user client.
 * --
 * Dates can be displayed in Twitter style (e.g. "1 hour ago") by setting the 
 * $twitter_style_dates param to true.
 * 
 * Credits:
 * Hashtag/username parsing based on: http://snipplr.com/view/16221/get-twitter-tweets/
 * Feed caching: http://www.addedbytes.com/articles/caching-output-in-php/
 * Feed parsing: http://boagworld.com/forum/comments.php?DiscussionID=4639
 */
 
function display_latest_tweets(
	$twitter_user_id,
	$cache_file = './twitter.txt',
	$tweets_to_display = 100,
	$ignore_replies = false,
	$twitter_wrap_open = '<h2>Latest tweets</h2><ul id="twitter">',
	$twitter_wrap_close = '</ul>',
	$tweet_wrap_open = '<li><span class="status">',
	$meta_wrap_open = '</span><span class="meta"> ',
	$meta_wrap_close = '</span>',
	$tweet_wrap_close = '</li>',
	$date_format = 'g:i A M jS',
	$twitter_style_dates = false){
 
	// Seconds to cache feed (1 hour).
	$cachetime = 60*60;
	// Time that the cache was last filled.
	$cache_file_created = ((@file_exists($cache_file))) ? @filemtime($cache_file) : 0;
 
	// A flag so we know if the feed was successfully parsed.
	$tweet_found = false;
 
	// Show file from cache if still valid.
	if (time() - $cachetime < $cache_file_created) {
 
		$tweet_found = true;
		// Display tweets from the cache.
		@readfile($cache_file);	
 
	} else {
 
		// Cache file not found, or old. Fetch the RSS feed from Twitter.
		$rss = @file_get_contents('http://twitter.com/statuses/user_timeline/'.$twitter_user_id.'.rss');
 
		if($rss) {
 
			// Parse the RSS feed to an XML object.
			$xml = @simplexml_load_string($rss);
 
			if($xml !== false) {
 
				// Error check: Make sure there is at least one item.
				if (count($xml->channel->item)) {
 
					$tweet_count = 0;
 
					// Start output buffering.
					ob_start();
 
					// Open the twitter wrapping element.
					$twitter_html = $twitter_wrap_open;
 
					// Iterate over tweets.
					foreach($xml->channel->item as $tweet) {
 
						// Twitter feeds begin with the username, "e.g. User name: Blah"
						// so we need to strip that from the front of our tweet.
						$tweet_desc = substr($tweet->description,strpos($tweet->description,":")+2);
						$tweet_desc = htmlspecialchars($tweet_desc);
						$tweet_first_char = substr($tweet_desc,0,1);
 
						// If we are not gnoring replies, or tweet is not a reply, process it.
						if ($tweet_first_char!='@' || $ignore_replies==false){
 
							$tweet_found = true;
							$tweet_count++;
 
							// Add hyperlink html tags to any urls, twitter ids or hashtags in the tweet.
							$tweet_desc = preg_replace('/(https?:\/\/[^\s"<>]+)/','<a href="$1">$1</a>',$tweet_desc);
							$tweet_desc = preg_replace('/(^|[\n\s])@([^\s"\t\n\r<:]*)/is', '$1<a href="http://twitter.com/$2">@$2</a>', $tweet_desc);
							$tweet_desc = preg_replace('/(^|[\n\s])#([^\s"\t\n\r<:]*)/is', '$1<a href="http://twitter.com/search?q=%23$2">#$2</a>', $tweet_desc);
 
 							// Convert Tweet display time to a UNIX timestamp. Twitter timestamps are in UTC/GMT time.
							$tweet_time = strtotime($tweet->pubDate);	
 							if ($twitter_style_dates){
								// Current UNIX timestamp.
								$current_time = time();
								$time_diff = abs($current_time - $tweet_time);
								switch ($time_diff) 
								{
									case ($time_diff < 60):
										$display_time = $time_diff.' seconds ago';                  
										break;      
									case ($time_diff >= 60 && $time_diff < 3600):
										$min = floor($time_diff/60);
										$display_time = $min.' minutes ago';                  
										break;      
									case ($time_diff >= 3600 && $time_diff < 86400):
										$hour = floor($time_diff/3600);
										$display_time = 'about '.$hour.' hour';
										if ($hour > 1){ $display_time .= 's'; }
										$display_time .= ' ago';
										break;          
									default:
										$display_time = date($date_format,$tweet_time);
										break;
								}
 							} else {
 								$display_time = date($date_format,$tweet_time);
 							}
 
							// Render the tweet.
							$twitter_html .= $tweet_wrap_open.$tweet_desc.$meta_wrap_open.'<a href="http://twitter.com/'.$twitter_user_id.'">'.$display_time.'</a>'.$meta_wrap_close.$tweet_wrap_close;
 
						}
 
						// If we have processed enough tweets, stop.
						if ($tweet_count >= $tweets_to_display){
							break;
						}
 
					}
 
					// Close the twitter wrapping element.
					$twitter_html .= $twitter_wrap_close;
					echo $twitter_html;
 
					// Generate a new cache file.
					$file = @fopen($cache_file, 'w');
 
					// Save the contents of output buffer to the file, and flush the buffer. 
					@fwrite($file, ob_get_contents()); 
					@fclose($file); 
					ob_end_flush();
 
				}
			}
		}
	} 
	// In case the RSS feed did not parse or load correctly, show a link to the Twitter account.
	if (!$tweet_found){
		echo $twitter_wrap_open.$tweet_wrap_open.'Oops, our twitter feed is unavailable right now. '.$meta_wrap_open.'<a href="http://twitter.com/'.$twitter_user_id.'">Follow us on Twitter</a>'.$meta_wrap_close.$tweet_wrap_close.$twitter_wrap_close;
	}
}
 
display_latest_tweets('YOUR_TWITTER_ID');
 
?>

Usage

You should edit the Twitter ID in the function call above before using the function (it appears at the very bottom of the code snippet).

You probably also want to edit the location where the twitter feed is cached – by default it is written to the root level of your domain. To change the location, modify the $cache_file variable, or pass the new location as a function parameter.

Notes

Twitter feeds may contain UTF-8 characters. I have found that running PHP’s utf_decode method on tweets didn’t have the expected result, so my recommendation is to instead set the charset of your HTML page to UTF-8. Really we should all be doing this anyway.

Credits

The hashtag/username parsing in my example is from Get Twitter Tweets by gripnrip.

My RSS parsing is based on replies in the forum discussion “embedding twitter tweets” on the Boagworld website.

The file caching is based on the AddedBytes article “Caching output in PHP”.

Changelog

v1.1.1, 28 January 2011

• Fixed bug in the logic that pluralises the number of hours since a tweet

v1.1, 14 January 2011

• Fixed URL parsing regular expression to make it much more liberal. It will no longer choke on hyphens.
• Added an optional parameter $twitter_style_dates which will format dates the same way as the Twitter website, e.g. “12 minutes ago”. It is set to false by default.
• Dates are now formatted the same as on the Twitter website, e.g. “3:48 PM Jan 14th”. This can be overridden using the $date_format parameter.
• The username parser will no longer include a trailing colon as part of the username, so the autolink for a string like “@username: hello!” won’t get messed up.

When I switched back to phpDesigner, the default blue-on-white color scheme seemed a tad boring, so I decided it was time to pimp my IDE! Unfortunately user created themes for phpDesigner are thin on the ground, which left me no option but to make my own.

PHP example:

HTML example:

CSS example:

JavaScript example:

I’ve named my theme Sunset, and it is inspired by the Midnight theme for SyntaxHighlighter. If any phpDesigner fans are looking for a light-on-dark color scheme to spruce up their code editor, perhaps Sunset will fit the bill.

Download

Download Sunset theme for phpDesigner

Installation and uninstallation instructions are included with the theme. Currently the theme has syntax highlighting colors for the four languages I work with: HTML, CSS, JavaScript and PHP.

Important

There is currently a bug in phpDesigner that sometimes causes the ‘separator’ colors to revert to their defaults (e.g. the color of <?php ?> tags reverts to black). The only sure-fire way to get things back to normal is to open the phpDesigner preferences dialog, and click ‘OK’. You might also try closing all your open documents and restarting the application. Hopefully this bug will be fixed in a future version of phpDesigner.

For most web designers, especially those who work solo, a custom built content management system is still a tall order. Fortunately there are numerous commercial and open source content management systems available, which offer a practical and affordable means of wrangling content. However, a “one size fits all” content management system that doesn’t address a site’s specific content requirements can introduce as many problems as it solves.

One page, one blob

The easier a content management system (CMS) is to configure and use, the more restrictive it is likely to be. HTML and CSS offer a rich toolset for describing and presenting all kinds of content, yet most CMSs cannot be configured to address the myriad types of content a content editor needs to display. Instead, the content editor is given the ability to modify just one “blob” of content per webpage. This format suits the majority of webpages, but assumes that the content editor is happy to have just one block of plain text per page, or that they are comfortable styling text with regular HTML tags, or a ‘simplified’ variation such as markdown. For the novice, HTML is hardly child’s play, and trusting a client to write compliant markup is optimistic to say the least. That’s where WYSIWYG (What You See Is What You Get, pronounced “wizzywig”) editors come to the rescue, and that’s when problems start to creep in.

The WYSIWYG problem

The WYSIWYG editor is at the heart of most modern content management systems, if not by design, then because web designers install one themselves. They are used as a “cure all” by CMS developers and web designers alike, because they provide content editors with a powerful interface for styling content, using a toolset that replicates the desktop word processors with which they are already familiar. The two most popular WYSIWG editors are TinyMCE and FCKEditor. Both use Javascript to enhance a regular HTML textarea, and do so via a menu of buttons similar to that found in Microsoft Word. This probably sounds ideal – a website’s content editor can take total ownership of their content, styling it in any way they please. But content editors are precisely that: editors. They are not designers, and shouldn’t have to – or be allowed to – make decisions that affect the design of their content. Sadly, this is exactly the power that WYSIWYG editors put at their fingertips.

Tinymce in all its glory. Watch your client destroy your layout in mere seconds!

Let loose with a WYSIWYG editor a content editor can mix and match font size, face and color, and even add tables, images, background colors, and emoticons to a webpage. If you think they will have the self control to exercise restraint, think again. Even the ability to alter the appearance of text can have disastrous results. I have seen a content editor use a WYSIWG editor to set body copy in 16 point, 12 point, and 10 point at various places on the same page, and in three different typefaces. Another client inexplicably changed the color of list items to exactly the same blue used throughout the site to indicate hyperlinks. The impact such misguided decisions have on usability and design should be obvious.

Of course the blame doesn’t lie with the content editor. They don’t have training as a graphic designer, nor can we expect them to grasp the subtleties of interactive design. The problem is that WYSIWYG editors mix the description of content (headings, lists, blockquotes) with its design (typefaces, colors, and point sizes). Web designers have long understood the importance of separating content from presentation, but WYSIWYG editors snatch that separation away from us.

Dial it back

Fortunately, most WYSIWYG editors allow you to limit their functionality to suit your needs. This can either be done using a CMS’s administration interface, or by editing a configuration file. When faced with a WYSIWYG editor I dial its functionality right back, leaving only the core set of tools needed to effectively describe content. Does a content editor need to specify background colors for text? Of course not. The size of text? Nope. Paragraph alignment? Uh-uh. Tables? Lets not even go there. I don’t even let a content editor underline text. Why? Because underlined text looks like a link.

Headings (h1, h2 etc), bold, italic, ordered lists, unordered lists, blockquotes, and hyperlinks: these should provide sufficient scope to describe most types of content. Let your regular CSS stylesheets style the output, and you’ll ensure the rendered content fits seamlessly with your existing website layout.

The copy and paste problem

WYSIWYG editors present another problem I haven’t touched on yet. Usually a website’s copy isn’t typed directly into a content management system, it is composed in a word processor, then pasted into the CMS. When this happens the formatting of the source text is brought across too, warts and all. Despite your best efforts to limit your client’s ability to style content, with one keystroke they can inadvertently bypass your safeguards. There are two solutions to this problem. The first involves education. Both FCKEditor and TinyMCE include a ‘paste as plain text’ button, that gives users the option of stripping all formatting from text as it is pasted into the WYSIWYG editor. The only problem is that your client needs to remember to use the button. The second option is more pro-active. Both FCKEditor and TinyMCE have a configuration setting that forces content to be pasted as plain text.

What about web standards?

A criticism often leveled at WYSIWYG editors is that they produce spaghetti code. In part, this is true. The only way a WYSIWYG editor can define the color of text, for instance, is by applying an inline style to your markup. But if you limit the WYSIWYG to a few core capabilities, as I suggested above, there is far less that can go wrong. The developers of WSIWYG editors are mindful of the need for standards compliance, and I have found that in most cases it isn’t hard to get both TinyMCE and FCKEditor to generate tidy markup.

Other options

Building a CMS from scratch is a huge task. I ought to know – most of my websites are powered by a CMS I built myself. Unless you are a competent programmer and have a heap of time up your sleeve (or just enjoy a challenge!), building your own CMS isn’t an option I would recommend lightly, but the advantages of the DIY route certainly pay off in the long run.

Building your own CMS gives you absolute control over how the software functions, allowing you to customize it to your own needs with fine grained control. When something breaks, you know how to fix it. If you want to add a new feature to the CMS, you just go ahead and add it, rather than submitting a feature request to the software vendor and crossing your fingers.

Another option to consider is XStandard, a WYSIWYG editor that touts its standards compliance and accessibility features. The big drawback I can see with XStandard is that it requires the content editor to install the XStandard application on their local machine. By contrast, a javascript based WYSIWYG editor makes your website editable from any computer sporting a modern web browser.

Whichever approach you take to content management, so long as you give careful thought to both your client’s needs and the pitfalls of giving them free rein, it is possible to strike a balance that keeps everyone happy. Giving clients the ability to edit their website’s content, and creating beautiful, standards compliant websites needn’t be mutually exclusive goals.

How they do it

An email is composed simply of raw text that is formatted using a standardized syntax. When we add a contact form to a website we allow our visitors to supply data such as their name, email address, subject and message, which we then format and send using PHP’s mail function. For instance:

<?php

  $recipient = 'recipient@mydomain.com';
  $subject = $_POST["subject"];
  $message = $_POST["message"];
  $headers = "From: ".$_POST["email"];
  mail($recipient,$subject,$message,$headers);

?>

will produce the following raw email data:

To: recipient@mydomain.com
Subject: Hello
From: sender@theirdomain.com

Hi, I love your site.

Seems harmless enough, right? We have hard coded the recipient’s email address in PHP, so it would be natural to assume that a visitor couldn’t use our contact form to send an email to anyone except the intended recipient.

Wrong!

Because we include the visitor’s email address in the email header, it is surprisingly simple for a malicious user to insert additional headers in the email field. They can do this in the following manner:

sender@theirdomain.com%0ABcc:recipient@anotherdomain.com

%0A is the hexidecimal representation of a linefeed, and forces a line break in the email’s header block. Now the raw email will look like this:

To: recipient@mydomain.com
Subject: Hello
From: sender@theirdomain.com
Bcc: recipient@anotherdomain.com

Hi, I love your site.

In this basic example the spammer has simply inserted a single additional recipient. In practice they will use more advanced injection techniques to hide your original message and display their own in its place, and will also insert the email addresses of thousands of hapless recipients. Now your form is being used to send spam.

As the hard coded recipient of the form, the website owner (your client) will become aware that something fishy is going on when they begin to receive large amounts of spam, apparently originating from their own site. Shortly your web host will also notice the high volume of spam emails being sent from your client’s domain, and shut the site down. They will send you an irate email requesting that your patch your insecure PHP scripts or find another hosting company. Needless to say, this chain of events is bad for your relationship with both your web host and your client!

The solution

Protecting against header injection attacks is a simple matter of validating user supplied data. Primarily, header injection relies on the attacker being able to include linebreaks in strings that will appear in an email’s header. By testing for the presence of these linebreaks in user-supplied data we can stop the spammer in their tracks. I have written a small function to simplify this process – it accepts as its parameter an array of the header fields we need to test:

<?php

function checkFields($values){
	$injection = false;
	for ($n=0;$n<count($values);$n++){
		if (eregi("%0A",$values[$n]) || eregi("%0D",$values[$n]) || eregi("\\r",$values[$n]) || eregi("\\n",$values[$n])){
			$injection = true;
		}
	}
	return $injection;
}

$from = $_POST['from'];
$email = $_POST['email'];
$result = checkFields(Array($from,$email));
if ($result==true){
	die("Header injection detected!");
}

?>

How to tell if your form is being exploited

To test a form to see if it is vulnerable, a spammer will first try and inject a single bcc header containing a throwaway email address (usually an AOL address). They then check that AOL address to see if they received the test email. If so, they will begin using your form as a spam relay.

The only flaw in this otherwise perfect plan is that the email’s intended recipient (whose email address is hard coded into your PHP form handling script) will also be receiving these probe emails.

So if one of your clients complains they are getting a lot of ‘spam’ sent to them via their contact form, sit up and pay attention. There is a chance the ‘spam’ they mention is actual a spammer’s probe emails. Ask your client to send you a few examples of the emails they are receiving. A probe will contain text that looks something like this:

said

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: an wan that makes me proud iv ailey f
bcc: onemoreaddress@hotpop.com

934522c25fb7a2507489e97c4043af14

I’m still getting annoying probe emails

Even though your form validation may already be filtering header fields for line breaks, you may still receive a spammer’s probe emails. This is because the spammer – or more precisely their ‘spambot’ – is attempting to blindly inject into every form field it finds, including the ‘message’ field (the probe example I gave above was actually the result of a spammer’s attempt to inject into the message field of a client’s contact form). The message field doesn’t pose a security risk since it does not appear in the email’s header, but unless you validate it as well then the form’s intended recipient will continue receiving probe emails. Of course the message field can legitimately contain linebreaks, so you will need to validate it for other telltale strings such as “Bcc:” or “Content-Type:” both of which are common in injection attacks. Make sure your validation ignores case, since an email header is case insensitive.

Conclusion

Validate, validate, validate. And don’t trust your website visitors, not all of them are good guys!

Further reading

Email Injection

For a really detailed description of email header injection in PHP, check out the Secure PHP wiki page on the topic.

Form Post Hijacking

When header injection attacks became widespread a couple of my sites were compromised. I found this article useful in helping me understand the problem.

UPDATE 12 Dec 2006: I realized that I had forgotten to double escape the \ characters in my validation function when I posted this article, so they weren’t showing up. Whoops! I have updated the function accordingly.

The image gallery was controlled by a Javascript which swapped the src parameter of a placeholder img tag each time the user selected a new image.

In my HTML markup I had a basic image tag with an ID applied to it:

<img id="placeholderimage" alt="" />

When the user selected a new image (by clicking ‘next’ or ‘prev’ in my image gallery navigation), a javascript was triggered to load a jpeg into the placeholder:

document.getElementById('placeholderimage').src = "mynewpic.jpg";

The problem with this method is that while the new image loads into the placeholder, the old image remains on the page. To the user it appears as if nothing is happening. The solution is to hide the image while it loads, and show the user some sort of load indicator while they wait. When the image has completed loading, reveal it again and hide the load indicator.

The specifics of hiding/revealing the load indicator are beyond the scope of this article, so I won’t bore you with them here. Instead I’ll demonstrate the method by which I hid and revealed the image, as that is what caused problems in Safari.

To hide the image, I used javascript to apply the CSS style display:none before loading the new jpeg. I also created an onload event handler for my image, to detect when it had finished loading. Inside my onload function I revealed the image again:

document.getElementById('placeholderimage').onload=function(){
        document.getElementById('placeholderimage').style.display = "block";
};
document.getElementById('placeholderimage').style.display = "none";
document.getElementById('placeholderimage').src = "mynewpic.jpg";

Easy peasy. The image is removed from the document flow when it starts to load, and returned when it finishes.

Everything seemed to be rocking nicely, until I fired up the site Safari 1.2. The image was hiding as expected, but my onload function was never evoked. After some head scratching I traced the problem to my use of display:none when hiding the image. I think Safari’s logic is that because the image is no longer part of the document flow, there is no point bothering to load it. Unlike other browsers, Safari never initiated the image load, and that’s why the onload never fired.

Armed with this new knowledge, we have a couple of “Safari friendly” options at our displosal:

• Use visibility not display

  If we use visibility = "hidden"; instead of display = "none"; to hide the image, everything works fine. The problem with using visibility is that the image is not removed from the document flow, meaning a gap is left on the page where the image used to be. Depending on the layout of your image gallery that may not be an issue for you – it may in fact be desirable. If it is an issue, you can set the height of the image (or it’s containing element if there is one) to zero, then use the onload handler to reset it to it’s correct height. Fiddly, but it works.

• Move the image outside the viewport

  If your image has the CSS property position:absolute, then you should be able to move it off screen by setting either it’s top or left property to a suitable low value, for example: left: -1000em; That ought to place the image off screen out of sight.

There may be other alternatives, and you can choose the one that suits you best. The important thing to remember is don’t use display:none to hide images while you swap their image source, or risk the wrath of Safari users!

For anyone interested to see the final implementation of my image gallery, here it is.