Using the .width() and .height() methods were working fine in every other browser but Safari, which I thought was a little bit odd. After trying to come up with an alternative method of coding calculating the heights and comparing them in FireBug and Web Inspector, I set about Googling the problem.

The only problem was that I had no idea what to search for, so started with the term “jquery height in safari”. The first result looked promising but took a fair bit of reading, although it proved to be worth while in the end. One comment pointed out that you should try to:

use jQuery(window).load() instead of jQuery(document).ready()

I tried this and straight away saw the results that were expected. The problem was that I didn’t really want to stop using the preferred document ready method ($(function() { … });), so searched the jQuery Bug Tracker for any sign of a bug report.

I eventually found one highlighting the exact problem I was having, issue #5521. The solution came in the form of a patch the document ready function that targets Safari.

+ if (jQuery.browser.safari && document.readyState != "complete") {
+ setTimeout( arguments.callee, 100 );
+ return;
+ }

It doesn’t look like this fix (nor any other form of solution) have been included in the latest nightly build, so I’m opting for the window load solution for now.

EDIT: Another solution to this problem is  to simply include any CSS files before the inclusion of the jQuery file. I found this by browsing the bug tracker and coming across ticket #3690.

One solution for this is to set a dimension (width or height) to the button.

To target Safari 3 in CSS you can use the following to add or override any existing attributes, such as the height of a button:

@media screen and (-webkit-min-device-pixel-ratio:0) {
	button {
		height: 40px;
	}
}

If required, multiple selectors can be added into a single block.

I tend to stick to Firefox as my development browser to test a project as I go along, this way I can almost guarantee that the layout will look fine when browsing in Opera, Safari (Win) and even IE7/8.

Internet Explorer 6 on the other hand is a whole different ball game altogether, even in standards compliance mode things can take an age to get sorted, often finding yourself floating elements as well as adding in any filters as it is unable to render png transparency or opacity correctly.

At least Microsoft had got the majority of things right when they released Internet Explorer 7 and now with the beta release of IE8 with the IE7 rendering engine option things are looking up for web developers.

Unfortunately we will have to put up with the woes of IE6 and below, at least until the percentage of users drops to a more insignificant amount. Currently around 30% of users are still browsing using IE6 which is enough to put doubt into every developers mind as to whether or not they should bother with it.

Currently I have Firefox 2 / 3 beta, Opera 9, Safari (Windows) and IE 8 (with built in 7 rendering option) all installed on my PC. Both Opera and Firefox allow for multiple installs of different releases on a single machine, but when it comes to IE6 I’ve had to either use the stand alone version or use a Virtual Machine with an XP and IE6 Image.

The stand alone version from Evolt is fine up until the point where you are wanting to test any filters, css conditional statements or set up a proxy connection.

The the virtual machine option on the other hand will render everything as expected, but does require you to go through the booting up process and download the latest image every couple of months as they expire.

With my irritations of backward compatibility aside, I believe as developers we should all continue to dedicate some of our time allowing as many people as possibly to have the same browsing experience, even though it can be a major chore at times and testing in each browser can have it difficulties.