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.

I was unable to find any additional debugging information on the error, which was also preventing the SMS and MMS application from displaying or even functioning. Any messages that were sent to me didn’t appear to be reaching me, even read receipts were stating that the message had been delivered.

In an attempt to salvage things I attempted to delete the last installed application – no luck. I then attempted a hard reset by pulling off the battery, leaving it for a minute and then replacing it and turning the phone back on – still no luck.

I then decided that it might be a good idea to carry out a factory reset…

Factory Reset Instructions:

I recommend starting the process by backing up any existing data – contacts, photos etc – using the Desktop Manager software.  Now we can move on to the actual reset process.

1. Press the menu key, the button to left of trackball, select the “Options” folder.
2. Scroll down and select “Security Options” then “General Settings“.
3. Press the menu key and select “Wipe Handheld“. A warning box will then appear to tell you that all application data will be lost. Select “Include third party applications” and then “Continue“.
4. Another box will appear asking you to enter the word “blackberry” to confirm the wipe. Doing this will restore the Bold to the factory settings.

If you decided to make a backup earlier, you may want to restore your data at this point.

You can now continue to use your Blackberry as before, without any additional applications installed. Some functionality may however have been lost, for example when trying to use the web browser you may get the error “This is a wi-fi service. Please ensure your device has an active wi-fi connection and try again.“.

This can be resolved by carrying out the following action:

Options > advanced > host routing table > menu (button left of trackball) > click on “Register Now.”

If at this point it is still not working, you should ensure that the default browser is set to “Internet Browser“:

Options > advanced > Browser > Default browser configuration > set to “Internet Browser”.

This process appears to have got everything back on track for me – relief.

Using the following code I managed to successfully read the width and height properties in FireFox 2/3, IE 6/7, Windows Safari 3/4 and Google Chrome, but the dimensions were not available in Opera (10).

$('<img alt="" />')
	.load(function() {
		$('body').append(this);
		var w = this.width;
		var h = this.height;
		//..
	})
	.error(function() {
		//..
	})
	.attr('src', '/path/to/image.jpg');

After a fair bit of time playing around trying to debug this small snippet of code, I eventually discovered that if the image was appended to the DOM after the width and height had been read then Opera would report the values correctly.

		var w = this.width;
		var h = this.height;
		$('body').append(this);
		//..

Simply moving line 3 down to below the reading of dimensions solved this issue.

$("#id").css({opacity: 0.8});

It turns out that the latest version of jQuery (1.3.1) doesn’t believe that Opera 9.2 supports CSS opacity, and therefore it is ignored completely.

There are two possible fixes for this, the first is to simply upgrade Opera to a newer version (the latest is 9.6.3).

The second option is to tell jQuery that opera does support opacity using the following – or similar – within your script:

if ($.browser.opera) {
    $.support.opacity = true;
}

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.

The Problem:

In the example below there is a standard button with 10px padding on all sides. Internet explorer chooses to add additional horizontal padding:

The solution:

After coming across this problem myself in the past, I eventually remembered that there are two CSS styles you can add to fix this bug feature in IE:

button {
	width: auto;
	overflow: visible;
}

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.

I wanted to split the lines of code displayed into a series of words with any spacing preserved, so started off by splitting each line on any none word “\W”.

var words = line.split(/\W/g);

This worked fine in Firefox, but when it came to IE the results were not quite what I was expecting. All the words were matched but all white space had been completely ignored, so instead I turned to using “\b” as the delimiter.

var words = line.split(/\b/g);

This took me a step closer to what was required but it was still not the desired result as I didn’t want any non-word characters to be grouped with alpha-numeric values, such as “123″.

I spent a little – in fact too much -time browsing the web for some pointers and came across an article posted on the SitePoint blog outlining the inconstancies of the String.prototype.split method across different browsers, which seemed explained the problem I was getting earlier but unfortunately offered no resolution.

Now to try and find a solution to all this.

Because splitting on “\W” was almost correct I reverted back to using that and now knowing what I had read over at SitePoint I somehow needed to prevent any non-word character sets from being ignored but without affecting the output in any way.

One possibility that arose was to wrap use the special character of null “\0″ around each section and then split on that value. I tried a long winded version of the following to see if it would take me any closer to the desired result and simplified it afterwords.

var words = line.replace(/(\W)/g, '\0$1\0').split('\0');

The output form this was pretty much almost what was required in both FF and IE, however it does not ease my frustration in the time wasted coming up and researching into this solution.

I can now continue on with my syntax highlighter in peace, or at least until the next major cross browser issue arises.

Whilst digging around for a reason he found that there was an inline style of “display: none;” applied to the image although no inline style was visible in the source code, which asked the question of where was it coming from?

As with many development and layout issues in Firefox they often come back to one of the many extensions or add-ons that you have installed – for example wondering why JavaScript isn’t working and then realising that it’s simply because you had disabled it earlier on to ensure your site will work without it enabled :S.

In this case it was found to be that AdBlock was installed, so by either disabling the AdBlock add-on or whitelisting the Fubra site and hitting refresh, all image problems appeared to have been resolved – for now.

A quick solution was applied for anyone visiting the site with AdBlock enabled in order to avoid the hiding of imagery.

For now I’ve renamed the images and it seems to have solved the problem.

I found it very interesting that the AdBlock extension would automatically block localised images simple because they contained the phrase ‘advertising’.

It seems to me that the add-on may be acting a little greedy here and should maybe only exclude images from third party websites containing this phrase or similar phrases if any.

After all, adverts are usually put in place for a reason and in a lot of cases without them it’s unlikely that the site would be there at all.