Bizarre: Tables Rendering Incorrectly in Firefox

[ugadarnell]

I'm working on the new site for the company at which I work. Our contact page is at the following address:

http://www.intellego-web-design.com/contact-us.php

The page looks fine in IE, but in Firefox is rundering the labels on top of the inputs. The only problem is that the labels are in a <th> cell and should appear to the left of the inputs, which all lie in <td> cells.

I tried creating a much simpler table elsewhere on the page, using only <td> tags, and I got the same problem.

I seem to have the same problem in Opera. But, it works fine in IE6 and IE7.

Can any of you see this as well? Any ideas as to what is going wrong here or ideas on how to fix it?

I'm calling it a day.

-Darnell

[Kravvitz]

It's because of this. IE thinks that table related elements, including <table>s, <tr>s, and <td>s, are display:block; by default. They aren't. <td>s are display:table-cell; by default, so Firefox was doing what you told it to do.

#overDiv table, tr, td, font{
	margin: 0;
	padding: 0;
	border: 0;
	display: block;
}

P.S. Why are you specifying styles for <font> elements?

[deathshadow]

Not to mention there's ZERO reason to be using a table there in the first place...

Though expecting forms to look the same cross-browser is unrealistic in the first place given how none of the browser makers have ever agreed on styling.

[Dan Schulz]

That's not entirely true, it's just (once again) Microsoft choosing to do things its own way...

[deathshadow]

That's not entirely true, it's just (once again) Microsoft choosing to do things its own way...

Microsoft NOTHING!!! IE 6 & 7 have well behaved forms compared to what those jokers who developed KHTML came up with... every time I deal with forms in Safari or Konqueror I have the overwhelming urge to punch out someone's lights.

Because of course, dayglow cyan C=64 highlights actually belong in a modern browser.

[Kravvitz]

Yes, Safari does style form controls differently from other browsers. Why shouldn't they? The specs don't seem to specify how the controls should be rendered. If a user doesn't like how Safari renders things he/she can switch to another browser, like Firefox or Opera.

I don't recall seeing Konqueror do what you describe. Safari's WebKit engine was based on Konqueror's KHTML engine, however, many changes have been made to both since then, so there are several differences now, which many people don't seem to acknowledge.

Newer versions of Opera have their own way of rendering buttons, but if I remember correctly, they do allow you to style them. So I suppose that's a bit different than the Safari situation.

[Dan Schulz]

Konqueror 3 and Safari 2 are functionally identical (for all intents and purposes) aside from Safari's refusal to allow styling of form elements themselves (meaning you get the default "ugly" look rather than being able to apply backgrounds and text color changes, and such, for example).

Opera does allow you to style the buttons as you see fit, and the only "differences" are just the ones related to how they are styled by default.

[Kravvitz]

Functionally identical? Konqueror 3.5 doesn't seem to support -khtml-opacity or opacity.

[ugadarnell]

First off, thanks for the suggestions. I'll let you guys know if I find a solution.

Kravvitz wrote:

It's because of this. IE thinks that table related elements, including <table>s, <tr>s, and <td>s, are display:block; by default. They aren't. <td>s are display:table-cell; by default, so Firefox was doing what you told it to do.

#overDiv table, tr, td, font{
	margin: 0;
	padding: 0;
	border: 0;
	display: block;
}

P.S. Why are you specifying styles for <font> elements?

I'm adding styles to a font tag because I have no control over the HTML in that part of the document. It is automatically created by the "OverLib" library. Because I am styling other elements on the page, it ruins the HTML attributes that style the OverLib tooltips, so I have to add them back in with CSS afterwards. It makes me sad to have to do it, but it works.

The problems I'm referring to are with the form that has id=contact_form, containing the table I'm using to lay out my labels and input elements. So, the styles that are being applied to the table are the ones beginning with:

#contact_form ...

deathshadow wrote:

Not to mention there's ZERO reason to be using a table there in the first place...

Though expecting forms to look the same cross-browser is unrealistic in the first place given how none of the browser makers have ever agreed on styling.

I'm using a table to lay out the form labels and inputs because I believe it's semantically correct. I have the labels in a <th>, followed by a <td> containing the element it is labeling. I added <label> tags in the <th>'s for usability. I think I actually read here on SitePoint somewhere that this usage of tables was semantically correct, as opposed to just being a way of laying out the elements. But I can't site the article in which I read it.

And, I'm not trying to do anything all that crazy with the table and its styles. I just want the cells on the same row to be side-by-side rather than on top of each other. I'm not looking for anything pixel-perfect here, but having cells of the same row appear on top of each other is a problem I've never encountered. It completely boggles my mind.

-Darnell

[ugadarnell]

It appears Kravvitz was correct about what part of my CSS was causing the problem, but I'm still baffled as to why. Here's the CSS:

#overDiv table, tr, td, font{
	margin: 0;
	padding: 0;
	border: 0;
	[B]display: block;[/B]
}

The display:block was causing the table cells to be displayed as blocks rather than table-cell's. But, this should only have applied to the <td>'s within the element with id=overDiv, correct?

For some reason, the rule was applying to all table cells on the page, which is what screwed up the table I was working on.

Is this a bug in Firefox/Opera? Or am I looking at this wrong?

-Darnell

[ugadarnell]

Okay. I see the problem.

This:

#overDiv table, tr, td, font{

Should have been this:

#overDiv table, #overDiv tr, #overDiv td, #overDiv font{

[Kravvitz]

Right. The comma allows you to apply the same rule to multiple elements, but it does not allow you to make part of one selector chain apply to another in the comma separated list of them.

Why do you want to make those <tr>s and <td>s display:block; anyway?

[ugadarnell]

Right. The comma allows you to apply the same rule to multiple elements, but it does not allow you to make part of one selector chain apply to another in the comma separated list of them.

Why do you want to make those <tr>s and <td>s display:block; anyway?

OverLib adds tool tips by creating a div, putting a one-cell table inside of it, then putting another one-cell table inside of it, then repositioning it on the screen when you roll over the appropriate item.

There are a lot of deprecated styling attributes being created dynamically for the tables, but luckily the CSS overrides these values. I made the rows and cells display as blocks to get rid of extra space that was being created somewhere in there. I don't know exactly what was causing the extra space, but displaying the rows and cell as blocks seems to have fixed the problem.

I wish OverLib was standards-based, but it seems to work alright without breaking validation.

-Darnell