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.

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!).

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.

The campaign leveredges Twitter to rally the web design community around the issue, and a realtime mosaic of the tweets can be viewed at fixoutlook.org. The site is worth a visit for this feature alone!

Further reading

Microsoft to ignore web standards in Outlook 2010 – enough is enough

In the following example IE7 considers the HTML comment to be the first child, and therefore my selector will fail.

CSS:

li:first-child { font-weight:bold; }

HTML:

<ul>
    <!-- IE7 thinks this comment is the first child. Oops! -->
    <li>The li:first-child selector should make me bold</li>
    <li>I'm the second child</li>
    <li>I'm the third child</li>
</ul>

Let me explain what I mean.

Instead of naming a div based on where it appears within my layout, I try to name it based on the content it describes. For example, rather than markup a site’s header as:

<div id="header">

I mark it up as:

<div id="branding">

and instead of:

<div id="footer">

I choose:

<div id="siteinfo">

The idea is that in the absence of meaningful, semantic HTML elements with which to markup content I use the most descriptive CSS id name I can think of.

How ironic then, that the new HTML 5 header and footer elements describe content based on where it appears on the page, rather than what it means.

Update 08 Dec 2007: I thought it was worth mentioning that the branding/siteinfo naming structure isn’t one I came up with myself – it is suggested by Andy Clarke in his book Transcending CSS.

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.

Validation is something I only do on my own work now.

Bowman was part of the team responsible for the 2002 redesign of Wired News using web standards and CSS. Wired News was one of the first major standards compliant sites, and helped pave the way for the web standards revolution. So for Bowman to state that validation of client websites is no longer an important consideration is quite an eye opener.

What designers like Bowman advocate is a pragmatic approach to web standards, an acknowledgment that validation is not practical in every situation. Non-compliant Content Management Systems and authoring tools, multi-developer teams and (let’s face it) poor attention to detail can all result in the production of invalid markup. When balancing the benefits of standards compliant markup against the time and cost required to overcome these obstacles, sometimes compliance is going to lose out.

I personally believe that web standards should be a cornerstone of any modern web design project. However, I also understand that given a limited timeframe and budget in which to produce a website, a certain level of compromise is sometimes inevitable, and perfectly acceptable. Consider the following common validation slip ups:

• Images missing an alt attribute
• Unencoded ampersands
• Empty <p></p> or <div></div> elements
• Uppercase XHTML tag and attribute names

All of these oversights will result in XHTML validation warnings or errors, but presently will not impact on the way a document renders or functions in a web browser. Neither do I expect these errors will cause significant problems in future browsers – I find it hard to imagine a web browser refusing to display a page simply because it contains an empty paragraph element.

Certainly if I notice any such errors during the development of a site I fix them straight away. However if I identify the errors at a later date, or they creep into the site during a content update, then I question the importance of correcting them immediately. In the past I would have dropped whatever I was doing and rushed to squash the offensive (but invisible) validation error, almost as a matter of personal pride. Today I am more inclined to add it to my to-do list for the next occasion I’m working on the site. In the meantime I know that both my client and the site’s user base will be totally oblivious to the ‘problem’.

In this discussion it is important not to lose sight of the benefits that standards based design undoubtedly brings to our workflow. Quicker development cycles, faster loading pages, simpler site redesigns, and improved search engine visibility are just some of the gains to be had by producing semantic and standards compliant documents. But our job as web designers is not merely to produce sites that adhere to the standards of our industry. There are also technical, budgetary and timeframe requirements to be factored in. By taking a pragmatic approach to validation it is possible to meet these demands without abandoning our commitment to web standards.

Now, it’s not too surprising that a website designed a few years back makes liberal use of tables and transparent spacer gifs for layout, but inexplicably all of the gifs have been given an img alt attribute of – you guessed it – “spacer.gif”. By itself this won’t cause display problems, but the href provided for the spacer gifs is also incorrect, meaning that the browser is unable to display the images. In combination these boo-boos cause Firefox to render the image alt values on screen, messing up an otherwise clean layout.

I’m surprised no one who works on the Exxon website has noticed this problem. I guess they all use Internet Explorer over there.

Until now, Outlook has stood its ground as one of the better email clients when it comes to rendering HTML. Sure, there wasn’t perfect parity between Outlook and Internet Explorer, but it was close enough to make do. However, with the switch to the Word rendering engine Outlook has taken a leap back into the dark ages, and now ranks somewhere alongside Lotus Notes and Eudora in terms of its rendering capabilities.

Here are a few of the significant HTML and CSS goodies you’re going to have to kiss goodbye:

• Background images
  Want a background image on that table cell or div? Forget about it friend, you have to make do with solid colors from now on.
• Floats
  Just when HTML email designers were tentatively proclaiming that CSS layouts were achievable, Microsoft have decided to rain on our parade.
• Flash
  Your recipients are just going to see a “red x” where the Flash movie would have been.

And that’s just the tip of the iceberg – you can see a complete list of the missing HTML/CSS elements, properties and attributes on the MSDN site.

None of these limitations is going to make the task of designing HTML emails impossible, but they will ensure that no advances are made in this field for a good number of years. Remember, it’s been four years since the last version of Outlook was released, so I’m going to guess it’ll be at least six years before Outlook 2007 drops off the edge of the map.

Microsoft are claiming that enhanced security is behind the decision, which seems odd considering how they keep harping on about how secure Internet Explorer 7 is compared to its predecessor. And as usual it’s the web designers – and consumers – who get shafted. Hopefully when Microsoft’s customer base realize how crappy their HTML newsletters now look, they will start consider alternative email clients such as Thunderbird. Maybe then Microsoft will realize how shortsighted they have been.

Further reading

Broken HTML/CSS Rendering in Outlook 2007

Joe Hardy has an excellent gripe about the situation, and details some of the specific problems you might encounter when designing HTML emails for Outlook 2007.

Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007

Straight from the horse’s mouth.