Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

IE v FF 1

Status
Not open for further replies.
livefree

livefree

Programmer
Jun 27, 2005
12
US
The following code works fine in IE 6.

<code>

table
{font-size: 12px;}

.Tables
{text-align: center;}

<div class=Tables>

<table ....>

</div>

</code>

The table is centered, & uses 12 px font.

However, in FF 1.0.4, the following is necessary:

<code>

tr
{font-size: 12px;}

<div class=Tables>

<table align=center ...>

</div>

</code>

But, both IE & FF interpret the following the same:

<code>

.Images
{text-align: center;}

<div class=Images>

<img src= ...

</div>

</code>

FF like IE centers everything (including text) in the Images class.

Is this a bug, some problem with my CSS code, or the harsh realities of strict CSS?

Other questions & answers may apply.

Thanks in advance.

livefree
 
Sort by date Sort by votes

It's more likely a DOCTYPE issue. What one are you using? If you don't specify one, then IE will work in "quirks" mode... exhibiting just the kind of unexpected and weird behaviour you are seeing.

Cheers,
Jeff

 
Upvote 0 Downvote
Table is a block level element and as such does not adhere to [tt]text-align[/tt] property. If you want to center a table, you need to put the following declaration in the table style: [tt]margin: 0 auto;[/tt]. This will work in all standard compliant browsers and IE6 with a proper doctype.
 
Upvote 0 Downvote
Many thanks, Vragabond. Your suggestion worked.

Still, it seems a bug in Firefox that it did not honor the 12px property to be assigned to the <table> type selector. It did OK with <body>, <div>, <p>, <td>, inline classes, etc., but not with <table>.

In any case, thanks for caring.

"Caring is the root of a civilized society. However, who cares about a suicidally-depressed grief counselor". Bend Over, Grief Counselor (1967-2004).
 
Upvote 0 Downvote
I think you might have another syntax error that's causing the font size problem. I ran this code with identical results in both IE and FF:
Code: 
<html>
<head>
<style type="text/css">
table {font-size:30px;}
</style>
</head>
<body>
<table><tr><td>Some Text</td></tr></table>
</body>
</html>

Mike Krausnick
Dublin, California
 
Upvote 0 Downvote
You're right, Mike. I made the simple change you suggested in the style sheet, assigning the font size to <table> rather than <td>. It worked, as it should.

If one can believe the W3C CSS syntax checker, there were no syntax errors in my external style sheets.

I could have sworn In true, full-flowered OCD fashion that I persistently tried the working solution at least 20 times. The fact that it didn't work was likely due to some browser-related issue.

Synching style sheets between IE & Firefox is my 2nd favorite thing in the whole world. My 1st is having an unclean yak sit in my dinner.

Thanks for the reply & the help.

George Mikos
Concord, CA

 
Upvote 0 Downvote

Yeah, well, sometimes CSS is half alchemy and half voodoo anyway.

Small syntax note: strictly speaking, all attributes should be enclosed in quotes, and in XHTML strict, case matters. Not sure whether you omitted them just for your code example here, but for example,
<div class=Tables>
Click to expand...
is more correctly written as
Code: 
<div class="Tables">
and
<table align=center ...>
Click to expand...
is more correctly written as
Code: 
<table align="center" ...>
But then, I'm just A-R about it.


Mike Krausnick
Dublin, California
 
Upvote 0 Downvote
They should be enclosed with quotes unless you are designing using tag soup (which usually includes elements being in uppercase/lowercase, some of their attributes being the same case and other attributes being the opposite case or even mixed case):

Code: 
<HTML>
<HEAD>
<TITLE>An example page</TITLE>
</HEAD>
<BODY>
<A hRef="example2.html" TITLE="Go to the main page">Main Page</A>
<P ALIGN=CENTER>An example <SPAN STYLE="color: orange">paragraph</SPAN>

<B>This should be in bold<I> and italics</B></I>
</BODY>
</HTML>

Ah, this brings back memories. :)
 
Upvote 0 Downvote
As far as I have experienced, browser differences between IE6 and other browsers (Safari, Opera, Geckos) are pretty minimal with proper doctype and correct coding techniques. Using very difficult designs require an odd hack now and then but that is about it. Sometimes IE's non-support for some very useful attributes (max-width, max-height) can be a pest, but it is not too bad. As for the table font-size hiatus in FF, it must have been a problem with the CSS. Web developer tool or DOM inspector would help you solve that because they can show you which css declaration relates to the object.
 
Upvote 0 Downvote
Vragabond,

Your statement that "As for the table font-size hiatus in FF, it must have been a problem with the CSS" is, at a minimum, hubristically assumptive.

As is the " ... are pretty minimal with proper doctype and correct coding techiques" statement.

Re 'doctype'. No comment.

Re 'correct coding techniques'. Is CSS correctly coded if it passes W3C's & WDG's CSS validation test, & the CSS validation test in TopStyle Pro 3.10? Or, is CSS correctly coded if it is rendered the same cross-browser? Or, is it both?

Finally, the statement "Using very difficult designs require an odd hack now and then but that is about it" belongs to the same class as the prior 2 cited statements; ie,

.hubristicallyassumptive
{content: 0;
empty-cells: googleplex;
overflow: toilet;}

The cross-browsers incompatibilites I've experience relate to very basic CSS properties; eg, margins.

Other than that, thanks very much for your response.

livefree
 
Upvote 0 Downvote
Thank you for your lecture, George. I do need to comment your statements a little bit though.

As far as being assumptive, I based that statement on the fact that Mike tested his simple code in IE and FF with same results, thus eliminating the option of a browser problem. Since a simple example worked, your code must have had elements that have thrown FF off. That is why I suggested using Web Developer toolbar or DOM inspector to look for the error (a suggestion you gingerly ignored). Not to mention I have seen working examples of this code hundreds of times, in these fora and elsewhere on the net.

Unfortunately, correct coding techniques in CSS cannot be determined by the validator or being rendered correctly in different browsers. They need to be learned by studying CSS and knowing how certain properties relate to certain elements, what goes with what and what doesn't. Validator will not give you an error if you try text-aligning class that is applied to a span element (even though span is inline and cannot have text-align property), but it is still incorrect coding. So I suppose it is all three. :)

Correct coding techniques also involves coding things properly. This is a very subjective term, however with time certain techniques have proven either bad or good. Employing the ones that are good give you much higher possibility of cross-browser compatibility.

Almost finally, regarding my statement about difficult designs. Again, this is a subjective term. I look at the design and if most of the elements are able to be rendered in normal document flow, that is usually a simple design. If the intricacies of design require coder to employ absolute positioning and negative margins, this will qualify as a difficult design.

I do not know how you can experience browser differences with margins, if you are using IE6 with a complete and valid doctype and comparing it to other browsers. IEs prior to version 6 had screwed up box model and margins were a big problem. However, since version 6 this has been rectified and margins should not be a problem anymore. If you still can produce a simple example that renders differently in FF and IE6 with a proper doctype, I will be happy to inspect it and give you my opinions. Even though you deem them as flushable.
 
Upvote 0 Downvote
Hmmm... just a thought about these doctypes again...

If you have anything (except whitespace) before your doctype statement, then IE will switch into quirks mode. You can send the file through the validators and they all say that the page is valid... but IE will be in quirks mode.

Example:
Code: 
<!-- this page will render in quirks for IE -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "[URL unfurl="true"]http://www.w3.org/TR/html4/strict.dtd">[/URL]

Before you launch ICBMs at one another... you might want to check some of these more obscure scenarios. Or not.

Cheers,
Jeff
 
Upvote 0 Downvote
vragabond,

Sorry. After reconsidering my last response to you, I humbly offer the following correction. It should have been "hubristically presumptive".

"As far as being assumptive, I based that statement on the fact that Mike tested his simple code in IE and FF with same results, thus eliminating the option of a browser problem."

However, you said it must be a CSS code problem. That was presumptive.

"Since a simple example worked, your code must have had elements that have thrown FF off. That is why I suggested using Web Developer toolbar or DOM inspector to look for the error (a suggestion you gingerly ignored)."

Again, presumptive.

(... responses to 3 paragraphs of lecturing pontifications mercifully omitted ...)

"However, since (IE) version 6 this has been rectified and margins should not be a problem anymore... If you still can produce a simple example that renders differently in FF and IE6 with a proper doctype, I will be happy to inspect it and give you my opinions."

Sounds reasonable. Here's the test program:


Incorporating Baby Jeffy's suggestion, I concentrated on DOCTYPE.

What I wanted to do was simple: Insert a blank line between the table title & the table. However, IE 6 & FF 1.0.4 rendered differently.

The test program has 4 permutations: With the loosest & strictest DOCTYPE, and with and without a </p> after <p class=TableTitle>. The 2 DOCTYPES used were:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN
"
The CSS code remained unchanged for all 4 permutations. Here are the results. 'Y' indicates a blank line was inserted:

IE FF
Loose, no </p>
Loose, </p> Y Y
Strict, no </p>
Strict, </p> Y Y

Duh. Now, I know. Yes, there are very good reasons to upgrade to strict XHTML.

Without the ending </p>, I was able to sometimes insert a blank line in IE, & other times in FF. If <p class="TableTitle...> was moved into the preceding "Text" class, all was copacetic, too, for reasona that are obvious now.

In any case, made the decision to upgrade my site to strict XHTML less than a week ago. With this ultimately trivial problem resolved, the most CSS-intensive document with a strict XHTML DOCTYPE works, & works identically in FF & IE.

The Web Developer toolbar is a good suggestion.

The XHTML community must be well-organized since good sites appear among the 1st few Google hits, with these sites cross-referencing one another nicely. As a result, good advice & tools seem to be easy to find.

I did a survey; its results might be of interest.

I surveyed 10 of Alexa's top 100 sites, all of general interest & none pure-Web related (ie, ad servers). The sites in ranked order were Yahoo, Google, ebay, Microsoft, Amazon, the BBC, CNN, Mapquest, Wikipedia, & the New York Times.

The Home Pages of these sites use nearly 100% pure scalable fonts: Yahoo, Microsoft, the BBC (perhaps the simplest, defining font sizes with numbers; eg, 1, 4, 6), Mapquest, & Wikipedia. CNN uses the reverse; ie, all font sizes are defined in pixels.

Of relevance here is their DOCTYPE's:

None: Google, eBay, & Amazon.
HTML 4.01 Transitional: Yahoo, Microsoft, the BBC, CNN, the NYTimes.
XHTML 1.0 Transitional: Mapquest, Wikipedia

As you might expect, the worst troglodyte site is the New York Times. Here are some sample font sizes: 3, 1, +1, -1, 11px, 10px, 12px, 82%, 125%, 78%. There's probably an em or ex somewhere in their labyrinthe, too.

In any case. if the results of this rigorous yet limited survey can be extrapolated, XHTML upgrading seems to be a seller's market.

Thank you for your very valuable time.

livefree
 
Upvote 0 Downvote
Without being able to see the whole of your code we have no choice but to be "presumptive", hubristicly or otherwise. Given that the questions you asked were about center-aligning a table and the inheritance of font sizes, and what you wanted to do was "Insert a blank line between the table title & the table" it's not surprising if you didn't find our answers very helpful. There's only so much presumption one can do.

A closing </p> is required in XHTML, if you miss it out browsers could do anything - error handling behaviour not being defined in the spec. A little bottom-margin on the element in question should do the trick.

However, since you're looking to put a title on a table, have you explored the <caption> element? It's a little bit more fiddly to style, but you get lots of brownie points for semantic purity. It may be a bit more accessible too. Do something like this:
Code: 
  <table class="eatme" cellspacing="0">
    <caption>Eat me permutations</caption>
	<tr>
	  <td>Perm #1</td>
	  <td>Perm #2</td>
	</tr>
	<tr>
	  <td>Mangez moi</td>
	  <td>ESSEN Sie MICH</td>
	</tr>
  </table>
with this:
Code: 
table.eatme {
  width: 37.5%;
}

table.eatme caption{
  text-align: center;
  font-size: 20px;
  font-family: Georgia, serif;
  padding-bottom: 1em; /* grrr, IE won't apply margin here */
}

table.eatme td {
  text-align: center;
  border: 1px solid #FFFF00;
  color: #FF6633;
  font-weight: bold;
  background-color: #99FF99;
  padding: 0;
  width: 50%;
}

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd
 
Upvote 0 Downvote
Thanks, ChrisHunt. I'll explore your suggestion. It has merit.

My original problem is resolved. Although the CSS validated both with W3C & WDG's CSSCheck, the HTML did not conform to HTML 4.01 strict or XHTML 1.0 Transitional; ie, no ending </p> tag.

Conclusion: At the minimum, all pages should be validated by W3C as HTML 4.01 strict.

livefree

 
Upvote 0 Downvote
You don't need a </p> in any version of HTML, strict or not. See
Start tag: required, End tag: optional
Click to expand...
That said, I think it's sensible to include the end tags, but it's not invalid to omit them.

In XHTML, by contrast, all elements must have a closing tag. The W3C validator usually does a good job of spotting instances where it's been missed out, I'm not clear from your post whether you validated the (X)HTML or just the CSS.

It's certainly worthwhile validating your pages as a first step in avoiding bugs, but the benefit of any particular doctype over another can be overestimated.



-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd
 
Upvote 0 Downvote
Chris,

Sorry for the late reply. Thanks for the info.

livefree
 
Upvote 0 Downvote
Chris, that is true of 4, but where it ends then is defined by the start of the next <p>, as with lists in 4.01...

And it certianly isn't true of xhtml:
section4.3
All tags must be closed with an end tag -- an empty tag must be it's own end tag. so <br> should be <br/> and <p>lalal<p>lalala should be <p>lala</p><p>lalala</p>

[plug=shameless]
[/plug]
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

bdwilcox
  • Locked
  • Question
More efficient / manageable way to code this HTA w/ VBScript?
Replies
0
Views
755
bdwilcox
bdwilcox
pendle666
  • Locked
  • Question
new website renders fine in IE/Edge but not in Chrome - test site was fine
Replies
2
Views
185
pendle666
pendle666
198709km
  • Locked
  • Question
Grouping XML key value using XSLT
Replies
0
Views
660
198709km
198709km
JScannell
  • Locked
  • Question
Testing embeddedc video files
Replies
2
Views
197
JScannell
JScannell
SitesMasstec
  • Locked
  • Question
Viewport meta tag x iframe
Replies
0
Views
152
SitesMasstec
SitesMasstec

Part and Inventory Search

Sponsor

Back
Top