How browsers can be misleading when handling errors

No, not a browser bashing article! Rather, a short collection of “quirks” that illustrates differences in how browsers deal with errors in CSS. For example, although Firefox is lauded as the be-all and end-all of browsers, and it may be more standards compliant than some of its major competitors, if you use Firefox as your main testing or development environment be aware that sometimes its intelligent approach to error handling can catch you out – as I’ve found out through personal experience. Here are a few examples.

1. Rating: +0

   

   Error in CSS for font-family declaration: font-family: arial, verdana, helvetica,;

   Have you spotted the error? Yes, it's the extra comma before the semi-colon. The correct code should be:
   font-family: arial, verdana, helvetica;

   Strangely, both FF and IE7 will display the correct font family, but Safari and Chrome (which is based on the Safari engine) will not. Instead, in Safari and Chrome all you will get is the browser's default font.

   This had me baffled for ages until I trawled through my stylesheet and found the extra comma...

2. Rating: +0

   

   Help! My stylesheet seems to be ignored by Firefox but my site looks fine in IE! What's going on?

   Perhaps not directly a CSS error handling issue, but in this example, the reason for this Firefox "quirk" only affects the stylesheet. The problem of "disappearing" styles in Firefox - but the site displays as intended in IE - is because you have spaces in your folder names.

   So, here's the tip:

   Make sure that your folder names do not include spaces! If you do, Firefox will not load your stylesheet. Strange or what?

3. Rating: +0

   

   Help! My site looks great in Firefox but my sidebar has disappeared to the bottom of the page in IE7!

   To be fair there are several possible reasons for this, not least being IE7's strict approach to the width of DIV elements. But in this case I'm referring to the how different browsers handle a missing closing DIV tag.

   Firefox will try to render the page correctly and in the absence of the missing DIV tag will make an "intelligent" guess as to how the content contained within the improperly closed XHTML element should be rendered. IE7 makes no such intelligent guess - hence the screwed up page in IE7.

   Frankly, I think Firefox is in the wrong here and should not render the page correctly if a DIV element is not closed properly. Just my opinion, but in this case I much prefer IE's strict approach to poor markup. Which leads me to believe that we should all probably use IE as our main testing environment rather than Firefox... but let's not start a browser-wars discussion! 🙂

4. Rating: +1

   

   The case of the disappearing image. An image within a post displays fine in Firefox but not in IE7. What's going on?

   I came across this one when answering a poster's question on the Revolution Two Support Forum.

   A quick review of the page Source revealed that the src attribute for the image commenced with http:///blahblah, in other wirds with three forward slashes rather than the correct two. It seems that Firefox "knows" this is an error and corrects it internally. IE7, on the other hand, just shows a broken link.

   Frankly, I think the Firefox developers have got it wrong here, and an incorrectly written URI should result in the image not being displayed.

That’s my short collection for the moment and I’ll add more as and when I experience them.

In the meantime, if you develop web sites, bear in mind that if you don’t continually test your site in different browsers – specifically, if you only rely on Firefox for your web development – don’t be surprised if you find your site doesn’t display as expected in other browsers, thanks to Firefox’s “clever” approach to dealing with CSS and code errors.