Fickle Firefox Frustrations!

[Creatix]

Hello WebProWorld Readers (and Writers),

I am having a new frustration today and, for the first time, I am going to ask you for some help.

One of my sites (http://www.newzealand-focus.com) is currently being translated into German. As a result I have spent hours recreating a lot of the content for a seperate German version.
Along the way I seem to be having a problem with visitors browsing with Firefox. I have searched high and low for the cause of the problem, but to no avail.
When the site is visited at the above link the English version displays as expected, but when you click the "Deutsch" link on that page, the equivelant German page has some breaks in images.

I thought this was caused by some long German words in the text or something, but have not been able to remedy the situation. I keep looking but do not see what is different in the code between my two versions. I did after all simply change the text, no code was adjusted.

Are there any Firefox experts out there that can shed some light on my failure? I really appreciate any help I can get.

Greg

[leonievs]

Hi

I opened your page in Homesite and I did run a tag validation on it.
First of all: <img> and <input> do not need/allow closing tags with them.
Some images end like this:
border="0" align="top" />, should be:
border="0" align="top">
Same with:
should be

And so on...

You say it is an exact copy but in the original version it says
<script Language="JavaScript">
if (top.frames.length!=0)
top.location=self.document.location;
</script>
and in the german not... Don't know why?

It seems very strange to me...
When I open the page in Homesite and place
<base href="http://www.newzealand-focus.com/de/">
at the top of the page, the page is previewing just fine...
So it seems like something that is happening online...!

I would first correct the HTML coding...
Firefox is just is not as easy as Explorer...

Good luck...

Regards,

Leonie

Web Design Department
MultiCards Internet Billing
www.MultiCards.com

[Creatix]

Thanks for your comments Leonievs,

The image tags and break tags do require a closing to conform with XHTML validation, hence they are there.

It is a strange problem though, like you say, and has now got me redesigning the entire site layout using only CSS. Maybe this will make a big difference to the overall site effectiveness.

Thanks again for replying.

Greg

[drummin]

Hi,
I looked at your site to see if I could figure this out. Seems that when I removed the doctype, things showed correctly in firefox.
I could not find anything else that could cause the the extra vspace in the top sections of your tables.
All images are the correct size for there locations and Text or links are not pushing the table apart.
Because I've no expert on doctype's, I can't help with this. It just displayed correctly for me when I removed it. Maybe something to look into.
Drummin

[scallihan]

Mozilla, Firefox, and Netscape (I presume) insert a margin underneath inline images nested inside of table cells, and also insert a margin abouve the first block element in a table cell, when running in standards mode, unlike Internet Explorer, which does not insert these margins. The first issue can cause havoc when using sliced images, while the second when creating table-based layouts.

A way to deal with this is to insert these two declarations in your page's style sheet:

td img { display: block; margin: 0; }
td :first-child { margin-top: 0; }

[corporateface]

I'm having a problem too.

Is there a resource on the internet for firefox/netscape/and ie code comparisons?

thanks

[MarcieZoob]

We help an auto dealership maintain a website built by GM which uses an online administrative interface for updates. We cannot use Firefox to update the site for some reason; we cannot upload our changes and move from page to page. We have to use Internet Explorer.

Not sure why and the GM Help Desk doesn't, either.

[paulhiles]

I'm just guessing here Marcie, but it could well be that the GM system uses a proprietary IE plugin or other such technology that only works with IE.
I've encountered many backend systems myself that are unashamedly geared towards IE users.

[MarcieZoob]

Paul, thanks for the feedback. I'm sure you're right in regard to IE plugins on this particular site. Our frustration was that the GM Help Desk didn't even know so, as a fluke, we tried it in IE instead.

With the rise in Firefox use and popularity, I imagine that they're going to encouter this tech support call more frequently.

[Webnauts]

My opinion is, that you must consinder cleaning up your code, which I found 55 errors and 25 other issues, which definetely cause browser compatibility problems.