Main Page Content
Don T Let Netscape Cramp Your Styles
Have you ever developed a web application with Sans-Serif fonts, just to be annoyed that on two of your pages the font suddenly changes back to Times Roman half way down. If you have, then you were using Netscape with styles. The situation has almost always been contributed to poor programming in Netscape and is often dealt with by using <FONT>'s and other poor practices to circumnavigate the real issue. But, the source of the errors has been discovered, and it is avoidable. It is a Netscape programming flaw; but, it is also due in part to Web Developer�s putting too much faith in Netscape�s bookkeeping ability. Before I explain the problem directly we must have a way to
Visualize How Netscape Handles Styles
Netscape starts parsing the page for display content at the <BODY> tag. At that point it has the style of the <BODY> in memory and uses it for all content. When Netscape encounters a section that overrides the <BODY>�s style--like a <DIV> with a style, id, or class attribute, or is styled with a selector in an inline or external style sheet--then Netscape pushes the <BODY>�s style onto a stack. If the new style does not explicitly identify every style for font and text, then it uses the information from the pushed style. *Note: Netscape neither supports nor "cascades" every font and text style, but a majority of those it does support it does cascade. It does not, for example, cascade text-decoration: blink, while it does cascade text-decoration: underline. (Go figure.)
Netscape Does Not Cascade Styles Into <TABLES>'s, and therefore may or may not push them onto the stack, but it definitely ignores the font and text styles up to that point.
That by itself is not a problem. It could be argued that you do not want to propagate styles into a table. But something happens to Netscape in tables. It seems to panic when it hits tables and start popping styles off the stack. When the </TABLE> is reached, we have fewer styles on the stack and a couple of </DIV>�s later and we have lost all styles. If the <FONT> was specified in the <BODY> only, then we are left without ANY reference to font and text styles. But what causes Netscape to panic in tables?
Malformed Tables Cause Netscape to Panic
Netscape is very strict on its rules with tables. Practices that are common, as I will show, can leave Netscape wondering what to do, therefore making it panic, and causing styles to be popped off the stack before the end tags.
So, to avoid making Netscape panic (since it does not make any sense to avoid styling TD�s) it is necessary to form tables correctly. Listed below is a list of no-no�s for creating tables. First off, Netscape only fails in the manner described if a <TD> within the table is styled through an ID, CLASS, or SELECTOR. The STYLE attribute to a <TD> does not produce the same failures. Though the list looks like common sense at first, if you have experienced problems with styles in Netscape, then you have made at least one of these--so, pay attention:
A malformed table exhibits at LEAST ONE of these characteristics
- At least one column has no pixel widths in a pixel width table.
- A single column has mixed percentage and pixel widths
- The table is defined with a percentage width. (Unfortunately, almost all configurations of this fail)
- At least one column is percentage width in a table and one of border, cellpadding, and cellspacing is not equal to 0.
- The summation of column widths of the table does not add up to the table width. The specified width of the
<TABLE>should take into consideration not only the cell widths, but also the border, cellpadding, and cellspacing. (Count pixels like your styles depended on it) - Percentage width columns should ONLY be used for tables with border, padding, and spacing=0.
- For each column, its percentage width * the table pixel width must be an integer. ie, you cannot split a 102 pixel table into three columns of 50%, 25%, and 25%. (102 x 0.25 = 25.5, which is not an integer) Gone of the days of a column being 25% of a table spanning 90% of the page and centered.
- and the list goes on and on...
Things to remember (web developers usually include all attributes to <TABLE>'s anyways, but):
- If omitted, cellpadding="1" is default
- If omitted, cellspacing="2" is default
- If omitted, even though no border is shown on the display by default, border=1 is spatially rendered, and therefore must be figured into
<TABLE>width calculations.
A table can cause a failure multiple times depending on the number of rows and columns. The logic behind the failures is consistent, but the behavior is complex. Further study into the behavior might produce a solid algorithm for predicting the number of failures, but since even one failure is unacceptable, it�s easier to simply form the tables correctly.
The failures can add up quickly, but the result is the same, styles are popped off the stack prematurely and the rest of the document from there down gets munched.
But Who Cares, I Put EVERYTHING in <TD>�s
Now, these rules can be broken and the browser will not crash. And, there are ways to avoid the problems associated with breaking the table rules. You could, for example, violate the rules on the outermost table if you do not plan on having any content at the <BODY> level after it. Or, you could place all displayable content in <DIV>�s and mandate a fully preemptive (every applicable style is declared) class on every <DIV>, or even put all content in a large <TABLE>.
But, even if you are cautious, it can happen that you notice nasty style droppings everywhere. So, if you do, check those tables carefully.
Thanks in large part to .jeff for help compiling the information for this article.
