Jim Correia and I spent a little time talking about this a few months ago, but I just noticed the problem again. Look at the following image:

The image on the left is how Firefox 2 and 3 render it. The image on the right shows the same image in Safari. (You won't see any image if you're reading this in email, you'll have to go to the link above.)

If you don't see the difference immediately, look at Lauren's face. The color in the one on the right is really good, and is why I marked this image as one of my favorites in both iPhoto and Safari. The color in Firefox is terrible. She's darker, and the skin tone is way off.

This is really annoying. I think I understand the basics of this problem, but I'm told that the root of it is the cost of licensing the colorspace technology (from Adobe?). Mozilla has more money than they know what to do with right now, and they have a lot of really smart people. I hope they solve this soon.

(Note that the picture looks pretty good in Internet Explorer, also. Of the three major browsers, Firefox is the only one with this problem.)

If you're running one of the FireFox 3 prerelase versions, you should install this theme. It's a pre-release version of the "mac look and feel" that Mozilla is preparing, bundled as a theme. I've read that they'll be shipping it with FireFox 3.0 when it's ready, but I now I can't find where I read it.

Huge improvement over what 3.0b1 ships with.

Note that "huge improvement," doesn't mean it's great. The toolbar area is now way too heavy and dark, which is exactly the oppsoite of Firefox 3's default theme. This theme is way better, but it's not nearly as good as Safari.

One of my clients has recently signed up for an online shopping cart system to work with his catalog (which is based on Conversant).

When a customer buys something through this shopping cart system, they're shown a confirmation page with a link back to a specific page on the vendor's site. That's totally standard.

The link appears to use JavaScript to submit a form which POSTs the sale's data (minus the truly private info like credit card number) back to a page on the vendor's site. Still pretty common (except their implementation doesn't actually work).

They claim that it only works in IE. Not in Firefox, not in Safari, not in Opera. Why worry about those, they're just a small percentage of the marketplace, right?

I'm sorry, but those people are morons.

Without even testing it, I can tell you that they're wrong: it doesn't work in ANY browser, not even IE. How do I know? The link just runs the script, and the script just causes the browser to navigate to the vendor's thankyou page: it never does anything with the form at all.

The form is all hidden fields, looking something like this:

<form action="url/of/thank-you/page" name="postData">
<input type="hidden" name="firstName" value="Seth" />
etc., etc., etc.

The form's action is pointing to the correct URL... but the form is never used. The script looks like this:

function submitForm()
{
	window.location.href="url/of/thank-you/page";
	return true;
}

If you understood the above, then you know how easy it would be to fix:

function submitForm()
{
	document.forms.postData.submit();
	return true;
}

Sigh. (Even easier: do away with the javascript entirely, and replace the link with an actual submit button.)

I'm surprised and happy to see that dbaron (one of the most experienced and "lowest level" (as in plumbing, not importance) Mozilla contributors) is finally working on an implementation of CSS 'display: inline-block'. I've been subscribed to the Bugzilla bug for inline-block for years and years, so I was amazed to see it finally get some official attention a couple days ago.

Apparently he's also implementing inline-table.

Some of us have recently been discussing the size of the Prototype library, my preferred library for DHTML/AJAX). Proponents of some of the other libraries play up their smaller file sizes, and it's true that this is a real issue for some people.

This little essay/how-to explains the basic ideas (the what, how, and why), and then walks you through setting up Apache on Mac OS X, to enable mod_gzip and serve compressed content. If you skip the editorial content and just follow the steps I've outlined, you should have everything up and running in fifteen minutes or less.

Read the Full Story