Here’s the original code cut from a larger object literal

isValid: function(hash) {
    return
        // Is cached AND
        typeof this.entries[hash] != "undefined" &&
        // Cache doesn't expire (e.g.: -1) OR hasn't expired yet
        (this.entries[hash].expires < 0 || this.entries[hash].expires > new Date().getTime());
}

After about 10 minutes and a gratuitous amount of debug output, I realized that this function was returning `undefined`.  “Nonsense,” I said to myself, “it’s returning a boole…wha…wait. Dammit.”

In my effort to document and format at the same time, I dropped the expression to the next line after the `return`.  Being that `return` by itself on a line is a complete and valid expression, JavaScript’s automatic semicolon did its thing and ended the statement there and my conditional expression was never evaluated.

Wrapping the whole conditional expression in parenthesis fixed the problem by invalidating the `return` line as a whole statement.

isValid: function(hash) {
    return (
        // Is cached AND
        typeof this.entries[hash] !== "undefined" &&
        // Cache doesn't expire (e.g.: -1) OR hasn't expired yet
        (this.entries[hash].expires < 0 || this.entries[hash].expires > new Date().getTime())
    );
}

Let that be a lesson to us all. I suppose it was bound to happen at some point.

So after some farting around with a couple of different candidates, I’ve decide to learn me some Python.  The runners up were Haskel and node.js.  Although incredibly interesting and a whole new way of thinking (functional vs procedural, that is), Haskel doesn’t seem like it would be immediately useful or practical.  As for node.js, since I already know JavaScript well, it’s more of just learning an API rather than a new language, which doesn’t seem like much of a stretch, but I’ll probably still tinker with it.

So Python it is, and I have two main motivations for choosing it:

1. It’s a respectable language that doesn’t get nearly the flack that something like PHP (which I still enjoy) gets.
2. Threading.  As I look more and more toward automation, this becomes more and more valuable.

It’s also been a really long time since I’ve picked up a new language.  New technologies, sure, but I haven’t started a new language since 2002 when I transitioned from C++ into PHP and JavaScript.  As such, any comparisons that I may draw, will likely be against those languages.

Another motivator for getting my ass in gear on this endeavor is Google’s Python class.  Having randomly stumbled upon it, everything has been put in motion.

Today, I got started with the introduction and chapter on strings.  Here’s the solutions that I came up with for the string exercises.  Python gurus feel free to offer a critique, but realize that the techniques that I’ve been exposed to are limited to the aforementioned chapters and a few cursory searches.

Basic exercise: string1.py

# A. donuts
# Given an int count of a number of donuts, return a string
# of the form 'Number of donuts: <count>', where <count> is the number
# passed in. However, if the count is 10 or more, then use the word 'many'
# instead of the actual count.
# So donuts(5) returns 'Number of donuts: 5'
# and donuts(23) returns 'Number of donuts: many'
def donuts(count):
  return "Number of donuts: %s" % (count if count < 10 else "many") 

# B. both_ends
# Given a string s, return a string made of the first 2
# and the last 2 chars of the original string,
# so 'spring' yields 'spng'. However, if the string length
# is less than 2, return instead the empty string.
def both_ends(s):
  if len(s) < 2:
    return ""
  return s[:2] + s[-2:]

# C. fix_start
# Given a string s, return a string
# where all occurences of its first char have
# been changed to '*', except do not change
# the first char itself.
# e.g. 'babble' yields 'ba**le'
# Assume that the string is length 1 or more.
# Hint: s.replace(stra, strb) returns a version of string s
# where all instances of stra have been replaced by strb.
def fix_start(s):
  return s[0:1] + s[1:].replace(s[0], '*')

# D. MixUp
# Given strings a and b, return a single string with a and b separated
# by a space '<a> <b>', except swap the first 2 chars of each string.
# e.g.
#   'mix', pod' -> 'pox mid'
#   'dog', 'dinner' -> 'dig donner'
# Assume a and b are length 2 or more.
def mix_up(a, b):
  return b[0:2] + a[2:] + " " + a[0:2] + b[2:]

Basic exercise: string2.py

# D. verbing
# Given a string, if its length is at least 3,
# add 'ing' to its end.
# Unless it already ends in 'ing', in which case
# add 'ly' instead.
# If the string length is less than 3, leave it unchanged.
# Return the resulting string.
def verbing(s):
  if len(s) < 3:
    return s
  return s + 'ing' if s[-3:] != 'ing' else s +'ly'

# E. not_bad
# Given a string, find the first appearance of the
# substring 'not' and 'bad'. If the 'bad' follows
# the 'not', replace the whole 'not'...'bad' substring
# with 'good'.
# Return the resulting string.
# So 'This dinner is not that bad!' yields:
# This dinner is good!
def not_bad(s):
  ni = s.find("not")
  nb = s.find("bad")

  if ni > -1 and nb > ni:
    return s[0:ni] + "good" + s[nb+3:]
  return s

# F. front_back
# Consider dividing a string into two halves.
# If the length is even, the front and back halves are the same length.
# If the length is odd, we'll say that the extra char goes in the front half.
# e.g. 'abcde', the front half is 'abc', the back half 'de'.
# Given 2 strings, a and b, return a string of the form
#  a-front + b-front + a-back + b-back
def front_back(a, b):
  a = half(a)
  b = half(b)
  return a[0] + b[0] + a[1] + b[1]

def half(s):
  l = len(s)
  m =  l / 2

  if l % 2 == 1:
    m += 1

  return [s[:m], s[m:]]

So there you have it, my first dive into Python.  Let me know what you think of my solutions and I’ll be sure to post my progress as I continue.

Understanding the problem

To solve any problem, you must first understand the problem. As programmers, we should all know this, as it is our business to solve problems. However, it’s not always clear to the client or coworker what their problem really is (although I’m sure we can point out a few). In order to finish something once, and to avoid that ridiculous state of being finished finishing, it’s important to have a solid understanding of the problem, and to be able to answer the “Five What’s.”

• What’s the goal
• What’s needed
• What’s not needed
• What can be done with other, existing solutions
• What does the client/coworker expect

First off, what’s the goal? This is deceptively simple, and answers that smack like, “to make a website,” are just begging the question. “To make a website to increase company exposure and generate sales from the Internet market,” is a real answer, and the type we’re after. Be sure to get at specifics, as that is what this whole exercise is about.

Second and thirdly, what is and what is not needed? If the goal of making said website is to drive sales and increase exposure, things like a solid SEO campaign and a web store are needed. But what about a neat-o staff section? That depends on the company and their product. How about customer tracking for Internet sales? I would say so. A contact form? Most definitely. Weather widgets? Bite me. Be realistic with each feature requested. Is it practical and useful, will it be used more than once, will anyone that’s not a local customer “get it” (i.e.: beware of gimmicks), is it worth the time to develop? These are the types of questions that you should ask yourself and your client/coworker when determining the project’s feature-set.

And what about what can be done with other, existing solutions? Don’t forget that there are a lot of out-of-the-box solutions for a wicked variety of things. However, if it will take away from your paycheck and the client can afford it, then as long as it meets the due date, I wholeheartedly encourage your to reinvent the wheel, the pencil, and to make better spatulas until the cows come home. But, for example, if you’re working on some internal project, chances are there may already be another tool that does just what your coworker is asking for. Use it, modify it if necessary, and spend your time doing things that actually need to get done (like reading reddit).

Lastly, what does the client/coworker expect? This “what” leads into my next point, because believe me, we aren’t out of the woods yet. You aren’t the only one that needs to understand the problem. We must also make sure that the client/coworker knows what’s up, and that we’re all on the same page.

Understanding the problem with the user

It may seem a bit redundant, but it’s true. Now that you’ve got all the pieces put together in your head (or on a white board), make sure that the client/coworker understands the problem to the same extent that you do. Often times, you may find that while you thought that you had a firm grasp on the task at hand, the client/coworker was saying one thing but trying to describe something completely different. Chances are the client/coworker is not a programming-savvy person, and that’s okay. The issue is that while a programmer would sit down and think about all the necessary features of some (hypothetical) admin tool, as well as, and more importantly, what might be needed in the future, the client/coworker will probably never try to look beyond their immediate needs. This leads to the painfully familiar situation of being a wee few hours away from finishing this great new tool, when suddenly it needs to have a translation system, tag clouds, region specific data, oven mitts, and an RSS feed to boot.

It’s important that you explain to the client/coworker how you understand their problem, the way you see their vision for this project, what you’ve understood as they’ve explained it to you. Explain to them what you’ll do—not how you’ll do it—and why the features that you will create are necessary. No one will be impressed with your technical jargon if they don’t know what you’re talking about, so unless necessary or well accepted, during all of this explanation be sure to spare the technical details, as it normally only muddles the matter further.

Thinking ahead

As mentioned earlier, clients/coworkers will hardly ever look beyond their immediate needs for a given project. It’s because of this lack of thinking ahead that clients/coworkers are prone to that we must reiterate the problem and its solution to the them in terms that they can understand, while even going as far to speculate about additional features that we think may be necessary now or in the near future. It has often been the case in my experience that while relating my own speculations for the project and my understanding of how the whole shebang is going to work, that many new-to-me but incredibly important features rise to surface.

Multiple perspectives

Today’s topic was spurred from an unfortunate situation that I recently fell into where a project at work has been unduly dragging on for well over two months. Worse yet, it’s still not done. I’ll take responsibility for that, but not for a lack of programming aptitude. Rather, I realized today that this whole mess arose out of underestimation and a lack of understanding of the whole picture as I’ve layed out here in this article. The real leason here is that, as developers, we must understand the whole picture from multiple perspectives: our own, how the client/coworker see it, and how the end-user sees it—but that’s a whole other story. More than that, we must also lead the client/coworker to the same understanding so that we are all on the same page, and to avoid suprises and curveballs further down the project timeline.

Author’s note: This article was originally posted at Frye / Wiles, and has been re-posted here for consolidation.

As a programming department, it is always our goal to code in such a manner that makes use of methods that provide, on average, the fastest execution times. In today’s discussion, we’ll be testing the many different ways to process and interact with arrays in PHP in the first of three main areas: reading, modifying, and reconstructing.

We’ve got some ground work to establish today, so modifying and reconstructing will be saved for later. Also, as time goes on, we’ll be talking about many different areas of PHP (like functions versus objects and static methods). But, for today, arrays have been chosen as our first point of discussion because, at least in my experience, they are more than ubiquitous when it comes to developing dynamic or content-driven applications, and dealing with large amounts of data (e.g.: user lists, pages, resources of all kinds, etc).

Preface

As PHP is an interpreted language, and all machines/OS’s/configurations/processors are not created equal, please note that results will vary from machine to machine. My configuration for these tests are as follows: AMD Athlon 64 X2 Dual core 6000+, 2 GB Kingston PC-6400, Windows XP sp2.

Getting started

When benchmarking, the goal is to determine the comparable time percent difference for a given group of methods; however, it is equally important to consider the data that being used in these test, and how it is applied. It’s best to use data that would reflect a real, or as close to real-world application as possible. We’re going to be dealing with a decent size array with 500 elements, each containing a string of 1024 bytes. In the real world, this could reflect a list of pages that we need to parse, or perhaps a list of comments to a blog post such as this one.

I’ve created a few generic classes to help me out with the nitty-gritty of the benchmarking process. At the end of this series on PHP-specific benchmarks, I’ll walk everyone through how to use these classes for their own tests. For today though, I’m just going to gloss over this groundwork and get on to the specific tests. Here’s how I’ve setup my test data and iteration control.

define('ITERATIONS', 10000);
define('ELEMENTS' , 5000);
define('VALUE_SIZE', 1024);

$ag = new ArrayGenerator(ELEMENTS, VALUE_SIZE);
$tc = new TimeCompare();
// The associative array run tests on
$a_assoc = $ag->generate(AG_TYPE_ASSOC);
// The indexed array to run tests on
$a_index = $ag->generate(AG_TYPE_INDEX);


Download the source code

As an extra benefit to those who download the source code, ArrayGenerator and all forthcoming Generators provide a small, mostly trivial lesson in PHP 5’s class inheritance and interface models.

Alright, lets get on with it.

Reading arrays

Right off the top of my head, whether they be associative or indexed, I can think of four different iterative structures that can be used to read through an array in PHP: for, foreach, list/each, and current/next.

For-loops have several variants. First, we will examine the traditional form, and then we will look at more optimized versions. In our test, we’re simply going to concatenate all of our array values into a separate variable. This test exemplifies the scenario where there are several pieces of data stored in array that need to be output to the page (sans formatting for us). Here’s the code for both indexed and associative arrays.

Indexed
$t = '';
for ( $i=0; $i<count($a_index); $i++ ) {
$t .= $a_index[$i];
}

Associative
$t = '';
$keys = array_keys($a_assoc);
for ( $i=0; $i<count($a_assoc); $i++ ) {
$t .= $a_assoc[$keys[$i]];
}

Indexed vs. associative arrays

The lesson here is to use index arrays when possible; however, this may only be applicable to for and other loops that use index counters. This may not apply to loops that use keys or other means of iteration; associative may be faster, it may be the same — we’ll find out later.

Now, lets be smart about our resources and move the count() statement outside of the loop-body and eliminate those extra n function calls. In general, we would write something like this.

Limit counting outside of the loop body
$limit = count($some_array);
for ( $i=0; $i<$limit; $i++ ) {
// ... do something ...
}

Now, applying this method to the previous two loops, lets retest to see what, if any improvement we get. I theory, depending on how count() behaves, this could be quite substantial.

Pre-counting the array size outside of the loop

Pre-counted vs. counting as part of the loop

Furthermore, if we switch from the post-increment operator, to the pre-increment operator, we should also see some time improvements. The difference is that in using the post-increment operator (a++), a copy of the variable is made, the original value is incremented, and then that copy is returned. With pre-increment operator (++a), the value is incremented and then returned, cutting the process down one less step. In general we would write something like this.

Pre-incrementing the loop counter
$limit = count($some_array);
for ( $i=0; $i<$limit; ++$i ) {
// ... do something ...
}

This gives us the following comparison.

Post vs. pre-incrementing

* We’ll refer to this last version of the for-loop as an optimized for-loop (limit pre-counting, pre-incrementing) from now on.

So now that we have everyone’s favorite for-loop thoroughly smashed (like an Idaho potato), lets move on to the other three methods for iterating over an array. In these final tests, we’ll be upping our test parameters a tad.

define('ITERATIONS', 1000000);
define('ELEMENTS' , 5000);
define('VALUE_SIZE', 1024);

The beauty of these final tests is that since the subscripts aren’t used, we can use the same code and just change the array names where necessary, and since we’ve spent so much time already, lets just put all the code out there straight away.

Foreach indexed/associative
$t = '';
foreach ( $some_array as $value ) {
$t .= $value;
}

List/each indexed/associative
$t = '';
while ( list(,$value) = each($some_array) ) {
$t .= $value;
}

Current/next indexed/associative
$t = '';
$value = current($some_array);
while ( $value !== false ) {
$t .= $value;
$value = next($some_array);
}

So now that we have our code, lets take a look at our results.

Interestingly enough, it appears that in the last three methods, associative arrays seems to out-perform indexed array by a slight amount, and although we’re talking only one to two percent differences, in the grand scheme of things, it all adds up.

So, overall, it appears that for is overall the winner of this match-up. with foreach, current/next and list/each following successively. For associative arrays, foreach appears to be the definite way to go being at least 4% faster than its closest rival, current/next. This is good news, since foreach is used so commonly in almost every piece of code in PHP that I’ve ever seen. It’s easy, and the good news is: its fast; but better than that, it appears, at least from this benchmark, that it is the right choice when dealing with associative arrays.

That does it for reading arrays. In the next post we’ll discuss array modification and reconstruction.

Author’s note: This article was originally posted at Frye / Wiles, and has been re-posted here for consolidation.

When we talk about topics such about CSS, JavaScript, and sometimes even certain image formats (png24, I’m looking at you), and how they render in a client’s browser, we always, or should always also consider cross-browser behavior. This behavior entails many things: CSS rendering, the availability of CSS specific attributes, whether or not the DOM interface will be the same, general JavaScript behavior — the list goes on and on. And, since most discussions about CSS and JavaScript (at least the ones that I am having) also concern this variable nature, I’m coining (maybe I’m the first) a new term to put all of this into a handy little phrase, “Cross-Browser Consistency,” or, in typical programmer fashion, simply, “XBC.”

Let’s take a brief moment to establish a more exact meaning for this phrase. As you may well be aware, the industry commonly talks about cross-browser support, so we’ll differentiate between support and consistency, as well as defining what cross-browser really means, and some other tidbits as to boot.

As we all know, the plethora of browsers out there leave some websites in a world of hurt as soon as you access them via an unintended environment. Between Firefox, Safari, Opera, and all the recent incarnations of Internet Explorer, there are a myriad of issues between the different browsers and their rendering results. Usually the discussion is focused on aesthetics and, more specifically, how the CSS may render; however, we should broaden the scope of aesthetics to look at the resolution and operating system too as they all have a hand in the end result. And don’t forget JavaScript! That’s always pushed off to its own thread of discussion, but I think its important that we consider it here. So, when talk about Cross-Browser Consistency, or XBC, we’ll need to be cognizant of two main areas: aesthetics and functionality.

Aesthetics

Browser aesthetics is not simply limited to how HTML and CSS are rendered, the concerns of which have already been discussed at length in various articles and wont be rehashed here. The important issue to realize is that the screen resolution and operating system that a given browser may be running in should also and always be considered as part of aesthetics.

Resolution and scalability

What happens when your site, designed for 1024×786 resolution is squeezed down into 800×600? Or, what about when someone has an even larger resolution, which is more and more common nowadays, like my dual 1680×1050 resolution? I’ll tell you that I’ve seen some funny, very unintended things. And, while these small and large resolutions may be at the extremes of the spectrum, they still entail a portion of your user base. These issues can be handled by designing “out of the box,” which is also known as using a “fluid layout.” We’ll discuss those some other time.

Have you ever considered what would happen if someone had a specific font size enforced via their browser? In some cases, the world would very well explode; however, if we implement our designs in a way that promotes flexible dimensions rather than fixed widths, heights, alignments and so on, we can account for a reasonable amount of font size variance in either direction. Our office standard is such that we allow for at least two font size increases (in Firefox, the hotkey is ctrl/command and +). For example, Yahoo’s home page scales incredibly well.

Operating system

In my experience, browser image scaling and font rendering (particularly for larger text) are the two main operating system-dependent issues that I’ve run into.

When I view a website, and they’ve used CSS or (gasp!) HTML attributes to resize an image, I am almost 110% sure that everything will look good enough for jazz in Mac OS X. However, load that same site in Windows XP or prior, and you’re bound to encounter the unexpected (unless you expected rough edges and other nasties). The difference comes from the two companies’ conflicting philosophies. They both think they’re right, but from a design perspective, I tend to lean toward the more visually appealing of the two, which happens in this case to be OS X.

When it comes to fonts, long story short: it’s better explained by someone else. Joel Spolsky provides an excellent read on the differences between Windows and OS X. One more thing to consider is that in XP (and possibly earlier versions), right out of the box clear type is disabled, and call it a hunch but most users would never know where, how or why to turn it on. Yet, at the risk of being kicked out of the Apple club, I have to say that Vista’s font rendering with ClearType is more readable than OS X. Please don’t shoot me.

Functionality

Libraries

If you’ve done much JavaScript at all, you’ve probably run into a handful of issues with some method existing in one browser and not in another. The first thing to realize is that unless you control the end-user’s client, browser-specific, proprietary methods should never be used. I always opt for the usage of distributed libraries, such as Prototype, jQuery, et cetera to prevent these issues as much as I can. However, it is also the case that the same method will be implemented in two different browsers yet behave differently (e.g.: innerHTML doesn’t on table and related elements in IE, et al), so it is always important to do some testing and research when necessary.

OMG noscript

Essentially, are you prepared to provide the same or similar functionality from the server-side as you have already provided via JavaScript? It is important, at least in non-elitist work, to exclude as little of a potential audience as possible. This means that we, as developers, must make certain allotments for users that don’t have or have disabled JavaScript. Typically, it is my stance that these users either aren’t accustomed to or expecting the bells and whistles of your fantastic JavaScript du jour, so providing similar, perhaps more basic functionality via the server-side language of your choice is acceptable and suggested.

XSLT

Yet another issue to consider is client-side XML/XSL transformations, or more to the point: does the browser support it and will it behave as expected. Normally, I would opt for the XSL transformations to be done on the server as this ensures that the markup you expected to be there . . . is there. Depending upon your server-side language, this has the added benefit of being able to import a namespace of functions from that language to be used in the XSLT as well. A bonus in my book for sure.

Tying it all together

So it didn’t turn out as brief as I intended, but we’ve covered a good bit of information. Cross-Browser Consistency ensures that a site’s presentation and behavior are the same. I’m going to actually be brief now and sumeverything up. Lists are always fun, so lets use one of those.

Cross-Browser Consistency refers to the following:

• Aesthetics
  • CSS support, rendering, and available attributes.
  • Resolution, fluid layout, and scalability.
  • Operating system rendering of fonts and browser-resized images.
• Functionality
  • Distributed, common libraries are preferred over browser-specific or proprietary libraries and methods.
  • Always provide an alternative server-side means of functionality for behaviors implemented in JavaScript.
  • XSLT is typically wiser to implement on the server to ensure broader support.

Author’s note: This article was originally posted at Frye / Wiles, and has been re-posted here for consolidation.

Today, we’re talking about color, its use on the web and how it is (in)effectively rendered cross-browser and cross-platform.When using a flat color as a background, such as is the case with the screen shot of salsa2night below, it is important to realize that if it is blending with an image, that some consideration of cross-browser rendering must be taken into account. Windows displays color differently than Mac, IE displays color differently than Firefox, which displays color differently than Safari–even when rendered on the same machine in the same OS.

Suppose that we have the following CSS declaration for an element on our page that contains an image that should blend in with a background color

#page {
background: #30899E url(image.ext) no-repeat;
}

The problem is not the hex value for the color, the discrepancy is in the value of the background color in the image itself. Here, on XP, Firefox is not agreeing with IE 6 about the image color; however, the CSS color of #30899E is being displayed consistently.

One way around this problem is by using IE conditional comments (which are a saving grace all to themselves, but that’s another topic) to include a style declaration or linked file to fix the background color for IE. These are also extremely useful for fixing other CSS, and sometimes Javascript, issues in IE that are inconsistent with other browsers.

<!--[if IE]>
<link rel="stylesheet" type="text/css" media="screen" title="FW" href="/css/ie/layout.css"></link>
<![endif]-->


or

<!--[if IE]>
<style>
#page {
background-color: #258095 !important;
}
</style>
<![endif]-->


This, however, doesn’t necessarily create a new problem, but does not remedy the entire situation in that it does no good for Safari and other browsers. Another, separate issue is that now you have two places to make modifications to every time you update the image instead of just one, but that’s really a different topic. If you’re market only includes IE or Firefox, then, I suppose, you can wrap it up here. However, when that day comes that you need to support more browsers, what then? In general, web sites aim to reach as big of an audience as available, and should, as part of that goal, strive to provide as consistent an aesthetic experience as possible. Getting down to the point: since there are no Safari, nor for that matter, Opera conditional comments, what are we to do? We’ve fixed things for two out of the four big players in the browser market, but now we need a more general solution that doesn’t involve copious amounts CSS hacks and gimmicks.

That general way of handling this color dilemma is by using web safe colors for the flat colors in images that will be also be painted by a CSS background color such as in the following declaration.

#page {
background: #003366 url(/images/my-image.ext) no-repeat;
}


Design suites worth their salt already have web safe color palettes as part of their color picking tools, so differentiating between safe and potential mis-representable colors should be a snap. The crux of the situation here is that these palettes were chosen and generated mathematically by design-challenged programmers (hey, I can admit it), and not by designers. Complaints of an over abundance of highly saturated colors and not enough of a selection of muted colors are common.

Adapting oneself to design within these color constraints is somewhat note-worthy, but not necessary. Enter method three: break it twice.

The general idea here is to have two images: the image that we’ve been dealing with all along, and another, 1×1 px, that is filled with the background color that we want to fill the area with that we had been originally using a CSS hex value for. The basic idea here is to have to div elements, on within the other. The outer div, page-background, will contain the 1×1 px image have it tile (repeat) in the X and Y directions. The inner div, page, will contain the main image as it always has, except that it will have no background color defined with it.

<style>
#page-background {
background: url(/images/my-image-background.ext);
}
#page {
background: url(/images/my-image.ext) no-repeat;
}
</style>
<div id="page-background">
<div id="page"></div>
</div>


Of course, height and width must be set on the page element to fit my-image and whatever content is to be included, but this is the general idea. This works because of one reason: we’re exploiting the inconsistency in the rendering of each image. If each of these images contain the same palette, then they will be rendered the same. Again, instead of using a CSS color value, we’re tiling a very small image that contains that color under the main image so that everything is displayed the same in all browsers.

Each of these methods for addressing the image color issue has their own draw backs: the conditional comments only work in IE and force a division of code that has to be updated in two places; the web safe color palette is limiting factor on design; and the final, break it twice solution has the overhead of an additional image, albeit small, as well as the extra mark-up needed to stylize and include the extra div element, which is, again, small but there nonetheless.

Of all of these, I prefer the use of web safe colors as it is definitely superior as far as implementation is concerned; however, when push comes to shove, using the twice broken or break it twice method will get the job done and can be, theoretically, guaranteed to work in all browsers, forever and ever, amen.