SitePoint Sponsor

User Tag List

Results 1 to 13 of 13
  1. #1
    SitePoint Member
    Join Date
    Mar 2006
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Unhappy 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

  2. #2
    CSS & JS/DOM Adept bronze trophy
    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;
    }
    P.S. Why are you specifying styles for <font> elements?
    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.

  3. #3
    Non-Member deathshadow's Avatar
    Join Date
    Jul 2006
    Location
    Dublin, NH
    Posts
    901
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  4. #4
    In memoriam gold trophysilver trophybronze trophy Dan Schulz's Avatar
    Join Date
    May 2006
    Location
    Aurora, Illinois
    Posts
    15,478
    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...

  5. #5
    Non-Member deathshadow's Avatar
    Join Date
    Jul 2006
    Location
    Dublin, NH
    Posts
    901
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dan Schulz View Post
    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.

  6. #6
    CSS & JS/DOM Adept bronze trophy
    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.

  7. #7
    In memoriam gold trophysilver trophybronze trophy Dan Schulz's Avatar
    Join Date
    May 2006
    Location
    Aurora, Illinois
    Posts
    15,478
    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.

  8. #8
    CSS & JS/DOM Adept bronze trophy
    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.

  9. #9
    SitePoint Member
    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;
    }
    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:
    HTML Code:
    #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
    Last edited by ugadarnell; Dec 18, 2006 at 09:11. Reason: Typo

  10. #10
    SitePoint Member
    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]
    }
    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
    Last edited by ugadarnell; Dec 18, 2006 at 09:12. Reason: Typo

  11. #11
    SitePoint Member
    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{
    Should have been this:
    HTML Code:
    #overDiv table, #overDiv tr, #overDiv td, #overDiv font{

  12. #12
    CSS & JS/DOM Adept bronze trophy
    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.

  13. #13
    SitePoint Member
    Join Date
    Mar 2006
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Kravvitz View Post
    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
    Last edited by ugadarnell; Dec 20, 2006 at 09:56. Reason: typos


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •