Kimili

Flexible Scalable Background Image

Michael Bester — Wed, 20 May 2009 22:06:35 GMT

When I get Photoshop comps from designers to build in HTML, CSS and Javascript, there are inevitably some elements of the designs which work well in ~~the Ivory Tower of~~ Photoshop, but present unique challenges when translating those elements into code a browser can work with. One such element on a project I recently completed featured a fixed size content area layered over background image that took up the entire browser window. The comp looked something like this:

The most striking aspect of the design, I think, is the full-window background image. When thinking about how to implement it, I considered what the client wanted as well as how I thought it should behave. When I combined those, the requirements I listed out for it seemed a bit daunting. It would have to…

Fill up the browser window, regardless of the window size.
Maintain the aspect ratio of the image (so it doesn’t distort like in a funhouse mirror).
Resize with the browser window as the window got bigger.
Maintain a minimum size that it would not shrink beyond.
Remain centered.
Not cause scrollbars.
Not be in the HTML as an element.

Now, I know this ground has been tread before, but the solutions I came across didn’t fulfill all of the requirements I needed. There was no way CSS was going to do it alone, even if I used CSS3’s ~~mythical~~ marginally supported background-size property.

The Basics

Let’s consider my last requirement first: Not be in the HTML as an element.

Since the image is a supporting design element, rather than integral to the content on the page, this was an important consideration. I didn’t want the template HTML to be cluttered up with a big image which wouldn’t make sense if you were to view the page with, say, a browser on a mobile phone. It would have to start with a background image on the element. I began by setting up the screen CSS with a definition like this:

body {
margin: 0;
padding: 0;
background-image: url(img/bg_page_default.jpg);
background-position: top center;
background-repeat: no-repeat;
background-color: #333;
/* This next one is for IE6 */
background-attachment: fixed;
}

For the project, I decided that the background images would be sized to 1280×960. With that CSS definition above, if you look at the site with a monitor that has that resolution or smaller, you’d see the image fill the window, remain centered, not cause scrollbars and basically fulfill all the requirements I listed above. All would be well.

But what if your monitor is bigger? What if it’s wider, taller or both? In that case, if you were to expand your browser window beyond 1280 pixels wide or 960 pixels tall, you’d see the dark grey background color, and that’s no good, because it would violate my first requirement: Fill up the browser window, regardless of the window size. It ends up looking something like this:

Clearly, we’re falling short so far.

Enhancing it for the Big Screen

To reiterate my 3rd and 4th requirements:

Resize with the browser window as the window got bigger.

Maintain a minimum size that it would not shrink beyond.

For simplicity’s sake, I decided that the minimum image size for the background would be the native size of the image itself (in this case, 1280×960 pixels). With the window any smaller than that, you’d see a portion of the image. It wouldn’t resize, and it would remain centered.

As the window gets bigger then that on one or both axes, though, we have to stretch the image to fill the available space. Since we can’t do that reliably with CSS yet, a different approach needs to be taken. I needed some Javascript to fill the void. Armed with it, I would:

Grab the URL from the background-image property on the .
Use that URL to create an element which I’d then append to the element.
Hide the new element when the browser window is smaller than the image.
Show the new element when the browser window is either taller or wider than the image.
Set the new element to either 100% wide or 100% high (but not both!), as necessary, to maintain the aspect ratio.

In order to take care of steps 3, 4 and 5, I opted to use some CSS to do that rather modifying CSS properties directly on the generated element, so I set up some definitions like so:

img#expando {
padding: 0;
margin: 0;
position: absolute;
display: none;
z-index: 1;
-ms-interpolation-mode: bicubic;
}
.wide img#expando,
.tall img#expando {
display: block;
}
.wide img#expando {
width: 100%;
height: auto;
}
.tall img#expando {
width: auto;
height: 100%;
}
.ie6fixed {
position: absolute;
top: expression((ignoreMe = document.documentElement.scrollTop ?
document.documentElement.scrollTop : document.body.scrollTop) + 'px');
}

Now, with those definitions, I can simply toggle a wide or tall class name on the element to hide and show the generated image, as well as determine whether it should stretch horizontally or vertically. I’ll set up a Javascript function to execute when the window gets resized which does the calculation and applies the necessary class name to the element.

As an aside, if you’re curious about the -ms-interpolation-mode: bicubic property, that’s in there to keep the image from looking, as Ethan puts it, janky in IE7 when it’s resized. You can peruse the geeky details on MSDN.

I think it’s important to point out that the first 2 steps above respect my first requirement – not be in the HTML as an element. Because we’ll use the URL of the ’s background image to create a new image element on the fly with Javascript, the image won’t be appended to the page if we don’t have Javascript available or our CSS doesn’t define a background image on the body, as might be the case if you had CSS files for alternate environments, like mobile phones for instance.

One detail I didn’t list out is that in order to respect my not cause scrollbars requirement, I’d have to wrap the generated image with a

. I’ll set that wrapper ’s width and height to 100% of the browser window’s width and height and apply an overflow: hidden to it, which will crop the image and prevent scrollbars from appearing. I’ll take care of this in the Javascript, as I only need to set those styles when the wrapper and the image are created.

Where it All Comes Together

So here’s a version of the script I came up with that pulls together all that functionality in its entirety:

var flexiBackground = function(){
/**
CONFIGURATION:
Define the size of our background image
*/
var bgImageSize = {
width : 1280,
height : 960
};
/**
Declare and define variables
*/
var $window = $(window),
$body = $('body'),
imageID = "expando",
tallClass = 'tall',
wideClass = 'wide',
$bgImage, $wrapper, img, url, imgAR;
/**
Are we dealing with ie6?
*/
var ie6 = ($.browser.msie && parseInt($.browser.version, 10) <= 6);
/**
Set up the action that happens on resize
*/
var resizeAction = function() {
var win = {
height : $window.height(),
width : $window.width()
};
// The current aspect ratio of the window
var winAR = win.width / win.height;
// Determine if we need to show the image and whether it needs to stretch tall or wide
if (win.width < bgImageSize.width && win.height < bgImageSize.height) {
$body
.removeClass(wideClass)
.removeClass(tallClass);
} else if ((win.w < bgImageSize.width && win.height >= bgImageSize.height) || (winAR < imgAR)) {
$body
.removeClass(wideClass)
.addClass(tallClass);
// Center the image
$bgImage.css('left', Math.min(((win.width - bgImageSize.width) / 2), 0));
} else if (win.width >= bgImageSize.width) {
$body
.addClass(wideClass)
.removeClass(tallClass);
$bgImage.css('left', 0);
}
// Need to fix the height of the wrapper for IE6
if (ie6) {
$wrapper.css('height', win.height);
}
};
return {
/*
Sets up the basic functionality
*/
initialize : function() {
// No need for any of this if the screen isn't bigger than the background image
if (screen.availWidth <= bgImageSize.width || screen.availHeight <= bgImageSize.height) {
return;
}
// Parse out the URL of the background image and drop out if we don't have one
url = $body.css('background-image').replace(/^url$("|')?|("|')?$;?$/g, '') || false;
if (!url || url === "none" || url === "") {
return;
}
// Get the aspect ratio of the image
imgAR = bgImageSize.width / bgImageSize.height;
// Create a new image element
$bgImage = $('')
.attr('src', url)
.attr('id', imageID);
// Create a wrapper and append the image to it.
// The wrapper ensures we don't get scrollbars.
$wrapper = $(' ')
.css({
'overflow' : 'hidden',
'width' : '100%',
'height' : '100%',
'z-index' : '-1'
})
.append($bgImage)
.appendTo($body);
// IE6 Doesn't do position: fixed, so let's fake it out.
// We'll apply a class which gets used in the CSS to emulate position: fixed
// Otherwise, we'll simply used position: fixed.
if (ie6) {
$wrapper.addClass('ie6fixed');
} else {
$wrapper.css({
'position' : 'fixed',
'top' : 0,
'left' : 0
});
}
// Set up a resize listener to add/remove classes from the body
$window.bind('resize', resizeAction);
// Set it up by triggering a resize
$window.trigger('resize');
}
};
}();
$(document).ready(flexiBackground.initialize);

Yes, yes, it’s using jQuery to help smooth out some of the rougher areas of Javascript like event handling and reading the CSS properties of elements, so if you’d like to use it as is, be sure to include jQuery on any page that uses this script as well (If you prefer, the script can fairly easily be ported to utilize a different framework or, with a little extra effort, none at all).

The project I’ve been referencing throughout this post is using a version of this script successfully – take a look at it in context. You can also take a look at a working example or download the script for your own use. Make sure that you include the CSS definitions above!

A Word of Warning

The resizeAction() method gets tied to the resize event on the browser window. Most browsers fire the event repeatedly as you resize a window, giving you a smooth transition between when you see the background image and the generated stretchy . Some browsers, however, wait until after you’re done resizing to fire the event, giving a decidedly ugly transition between the two. The most notable offender is Firefox and other Gecko based browsers. This is a long standing bug, going back to the Netscape 4 days(!), and it looks as if the Mozilla team has finally fixed it in the upcoming Firefox 3.1/3.5 release.

In Parting

If you’ve found this useful, I’d love to hear your thoughts on how it could be improved upon and any ways you take it and make it your own. Either leave a comment or email me.

Plugin Update: Kimili Twitter Timeline v1.2

Michael Bester — Tue, 17 Feb 2009 22:07:57 GMT

Fresh off the press, here’s a new version of Kimili Twitter Timeline, the best way to put your Twitter feed on your Textpattern site. This version covers the requests people have had and adds a bit more flexibility in configuring how tweets are displayed on your site. New features are:

Private account authentication! – Now you can display your tweets even if you have a protected account set up.
Any Textile formatting in tweet text can now be parsed as Textile.
You can now customize link text in the footer.
Changed feed request method from fopen to curl, which is more flexible and should be more compatible for some who were having problems retrieving their feed.

Read more about it and download it on the Kimili Twitter Timeline home page.

A Retort - IE8 Blacklist: Forcing Standards Rendering Opt-In

Michael Bester — Fri, 13 Feb 2009 20:17:12 GMT

A blog post making the rounds in web development circles today argues that a new feature in Microsoft’s Internet Explorer 8 (currently in pre-release) presents another major obstacle in the way of standards-based web development. That post is almost completely wrong.

The post in question, IE8 Blacklist: Forcing Standards Rendering Opt-In, points out the fact that Microsoft is implementing a “compatibility list” for its upcoming release of Internet Explorer 8, which will, in effect, trigger the browser to render a site on that list as if it were being displayed in IE7. Further, the list is generated primarily by users of IE8 who think a certain site doesn’t look right in the browser (IE8 will default to standards-compliant page rendering) and click on the browser’s “Compatibility View” button. If enough people click on that button for a given site, Microsoft takes note of it and adds that site to the compatibility list.

Anybody who knows me and how I prefer to work can tell you that I’m no Microsoft loyalist or sympathizer by any means, but Mike Davies, the author of the IE8 Blacklist post, is really overreacting here.

If you read through the Microsoft IE blog post, Compatibility View Improvements to come in IE8, which Davies sources to form his argument, you’ll see one thing that he fails to point out is that the compatibility list (Microsoft avoids the term “blacklist” in the post) only keeps track of “high-volume” sites:

The sites on the list are based on objective criteria applied to telemetry data as well as product support channels. For example, in addition to the top sites worldwide, we determine high-volume on a market-by-market basis; the top 50 sites in one region of the world might be very low on the world-wide list of top sites, but are important to include for those customers.

By “high-volume” sites, Microsoft is referring to

…sites like facebook.com, myspace.com, bbc.co.uk, and cnn.com...

Davies uses A List Apart as an example of a site that could inadvertently get blacklisted into rendering in compatibility mode. As popular a site as ALA is in the web industry, it is FAR from one of the top sites worldwide. As of today, Alexa puts its rank at 59,067, and Quantcast puts it at 43,450. Not exactly the top 50 in any market, and therefore not “blacklistable”.

Additionally, he fails to point out that Microsoft will do outreach to owners of sites which have been blacklisted to let them know and help them out:

We reach out to those sites (beyond all the other outreach we’ve already done!) to make sure they know the experience their IE8 visitors have by default and what steps they (the sites) can take to make it better. We also tell them that in the meantime, we’re adding their site to this compatibility list and provide instructions on how the site can opt-out. (If a domain notifies Microsoft that it’s choosing to opt-out, we remove it from the list at the next scheduled list update.)

While it’s not entirely clear exactly how Microsoft will determine what qualifies as a “high volume” site, what is clear is that most sites – especially niche sites maintained by individuals who care deeply about web standards – don’t make the cut. We’re just not in the same league, traffic-wise, as Google, Facebook, MySpace or CNN.

Put yourself in Microsoft’s position. They have a tremendous weight of legacy sites and applications written with proprietary code that they don’t want to break with a browser upgrade. They also realize they’re way behind the curve when it comes to supporting current and future web standards. I do believe they’re trying to do as much as they can to serve both issues and for that they should be commended.

Kimili Flash Embed 2.0.1 - For Real!

Michael Bester — Mon, 19 Jan 2009 03:05:14 GMT

I’m happy to announce that last night I pushed Kimili Flash Embed 2.0.1 live! Utilizing SWFObject 2.1 and taking advantage of all that it has to offer, this new version represents a major overhaul of KFE – in fact, it has been completely rewritten from the ground up. Gone are some of the madding weak points of the 1.x version of the plugin—Wordpress 2.7 incompatibilities and Textpattern Legacy and Current SWFObject modes among them. New to KFE 2 are a number of things that will make working with SWFs on your site much easier, such as:

An integrated tag generator to help you build KFE tags easily.
Configuration options
A super easy way to define alternate content for your SWFs.
All of the newest Flash Player parameters, such as seamlesstabbing and allownetworking are available.

By the way, in case you’re curious, 2.0.1 is the first proper release of the KFE 2.0 branch—it really should be 2.0. Some troubles I had with the way the Wordpress Plugin Directory during this version’s development and how it handles versioning necessitated the bump in version numbers to keep Wordpress’ auto plugin updating in sync. Consequently, no KFE 2.0.0 for Textpattern exists.

On another note, this version represents the first time Kimili Flash Embed is localizable. I’ve released it with just US English for now, but if anyone reading this would be willing to do a translation, please contact me. You’d be doing a great service by helping the community of plugin users who speak your language.

Go ahead, check out all the details and download it on the Kimili Flash Embed homepage.

Shake

Michael Bester — Mon, 12 Jan 2009 18:58:51 GMT

It’s been pretty snowy here in New England as of late, but Kiev doesn’t mind.