SitePoint Sponsor |
|
User Tag List
Results 1 to 13 of 13
-
Dec 15, 2006, 15:28 #1
- Join Date
- Mar 2006
- Posts
- 5
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Bizarre: Tables Rendering Incorrectly in Firefox
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
-
Dec 16, 2006, 23:57 #2
- Join Date
- Mar 2005
- Location
- USA
- Posts
- 5,482
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
Code:#overDiv table, tr, td, font{ margin: 0; padding: 0; border: 0; display: block; }
We miss you, Dan Schulz.
Learn CSS. | X/HTML Validator | CSS validator
Dynamic Site Solutions
Code for Firefox, Chrome, Safari, & Opera, then add fixes for IE, not vice versa.
-
Dec 17, 2006, 15:14 #3
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.
-
Dec 17, 2006, 19:15 #4
- Join Date
- May 2006
- Location
- Aurora, Illinois
- Posts
- 15,476
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
That's not entirely true, it's just (once again) Microsoft choosing to do things its own way...
Save the Internet - Use Opera | May my mother rest in peace: 1943-2009
Dan Schulz - Design Team Advisor | Follow me on Twitter
SitePoint References: HTML CSS JavaScript | Become A Guru
WordPress SEO Checklist | What WordPress Plugins Do You Use?
Web Standards Curriculum | Image Free Equal Height Columns
-
Dec 18, 2006, 00:35 #5
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.
-
Dec 18, 2006, 02:31 #6
- Join Date
- Mar 2005
- Location
- USA
- Posts
- 5,482
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.We miss you, Dan Schulz.
Learn CSS. | X/HTML Validator | CSS validator
Dynamic Site Solutions
Code for Firefox, Chrome, Safari, & Opera, then add fixes for IE, not vice versa.
-
Dec 18, 2006, 03:20 #7
- Join Date
- May 2006
- Location
- Aurora, Illinois
- Posts
- 15,476
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.Save the Internet - Use Opera | May my mother rest in peace: 1943-2009
Dan Schulz - Design Team Advisor | Follow me on Twitter
SitePoint References: HTML CSS JavaScript | Become A Guru
WordPress SEO Checklist | What WordPress Plugins Do You Use?
Web Standards Curriculum | Image Free Equal Height Columns
-
Dec 18, 2006, 03:31 #8
- Join Date
- Mar 2005
- Location
- USA
- Posts
- 5,482
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Functionally identical? Konqueror 3.5 doesn't seem to support -khtml-opacity or opacity.
We miss you, Dan Schulz.
Learn CSS. | X/HTML Validator | CSS validator
Dynamic Site Solutions
Code for Firefox, Chrome, Safari, & Opera, then add fixes for IE, not vice versa.
-
Dec 18, 2006, 08:54 #9
- Join Date
- Mar 2006
- Posts
- 5
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
HTML Code:#overDiv table, tr, td, font{ margin: 0; padding: 0; border: 0; display: block; }
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:
HTML Code:#contact_form ...
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.
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.
-DarnellLast edited by ugadarnell; Dec 18, 2006 at 09:11. Reason: Typo
-
Dec 18, 2006, 09:08 #10
- Join Date
- Mar 2006
- Posts
- 5
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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:
HTML Code:#overDiv table, tr, td, font{ margin: 0; padding: 0; border: 0; [B]display: block;[/B] }
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?
-DarnellLast edited by ugadarnell; Dec 18, 2006 at 09:12. Reason: Typo
-
Dec 18, 2006, 09:18 #11
- Join Date
- Mar 2006
- Posts
- 5
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Okay. I see the problem.
This:
HTML Code:#overDiv table, tr, td, font{
HTML Code:#overDiv table, #overDiv tr, #overDiv td, #overDiv font{
-
Dec 20, 2006, 04:05 #12
- Join Date
- Mar 2005
- Location
- USA
- Posts
- 5,482
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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?We miss you, Dan Schulz.
Learn CSS. | X/HTML Validator | CSS validator
Dynamic Site Solutions
Code for Firefox, Chrome, Safari, & Opera, then add fixes for IE, not vice versa.
-
Dec 20, 2006, 09:54 #13
- Join Date
- Mar 2006
- Posts
- 5
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-DarnellLast edited by ugadarnell; Dec 20, 2006 at 09:56. Reason: typos
Bookmarks