Does Netscape 6 Break Your Table Layouts?

Posted on December 26, 2000

in Code

by James Aylard (jaylard)

Rated 4.46 (Ratings: 35) (Add your rating)

Want more?

More articles in Code
More articles by jaylard

James Aylard

Member info | Full bio

User since: November 18, 1999

Last login: November 18, 1999

Articles written: 7

When it comes to installing new software, I'm like a two-year-old at Christmas, excited by the prospect of every new feature, interface widget, and performance improvement promised by the product. The fact that one or more of my childlike expectations is nearly always either partially or wholly disappointed rarely seems to dampen my enthusiasm for the next new product. Yeah, I'm a sucker -- a software sucker.

When it came to installing the release version of Netscape 6, however, my normal enthusiasm for the latest thing was far more reserved, informed by installing and testing numerous Mozilla milestone builds and two preview-release versions of the Netscape-branded browser. My experience had sobered me with the realization that this was a browser of immense promise, but which was traditionally buggy and evolved slowly.

My sobriety proved justified: after installing the release version of the browser, I was perplexed to discover that it added unsightly vertical spacing to pages that I had designed, and broke pixel-precise layouts, undoing hours of my design work without any obvious explanation. This was all-the-more confusing because, as far as I could recall, none of the earlier Mozilla builds or Netscape preview releases shared this problem.

I wrote my pages to be compliant with the HTML 4.01 Transitional DTD, and the W3C validator verified that they were. My page layouts were moderately complex, so I began the process of dissecting them piece by piece to see at what point Netscape 6 balked at displaying them properly. I took away everything that was extraneous including scripting and style sheets, peeled my nested tables apart, and began at the most-basic level of simplicity. Netscape 6 smiled, displaying my basic table correctly.

I re-nested my tables, and still Netscape 6 smiled.

I added back in the CSS, yet Netscape's sunny demeanor remained undiminished.

It wasn't until I added the document type declaration that Netscape frowned and broke my layout. Hmm. "Strange," I thought. I had taken my document type declaration straight from the HTML 4.01 recommendation itself:

&lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"<br>

���"<a href="http://www.w3.org/TR/html4/loose.dtd" target="_blank">http://www.w3.org/TR/html4/loose.dtd</a>"&gt;

Nonetheless, the browser treated this fully valid declaration just as if it were a figment of my imagination. Further tinkering finally brought the solution: Netscape 6 apparently only recognizes a single, particular URI within the transitional document type declaration:

&lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"<br>

���"<a href="http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd" target="_blank">http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd</a>"&gt;

Although the content of these DTDs is identical, using the URI of the first document type declaration will break the page in Netscape 6 whereas using the URI of the second will prove successful. My pixel-precise table layouts are properly aligned once again. With that solved, Netscape 6 and I are both smiling.

47 comments on this article. Log in to add your comment |

Correction

Submitted by jaylard on December 27, 2000 - 16:10.

I thought I had kicked the tires on this whole thing pretty thoroughly, but I've since come to realize that I was off the mark on a key point: Referring to the document type declarations above, Netscape 6 actually does recognize the first one, and not the second one (I have just read an interesting article by Henri Sivonen about this). The actual problem appears to be that Netscape 6 actually applies the Strict DTD to a document with the first DTD, instead of the Transitional DTD as it should. I will do more study on this to sort it out more clearly.

In a way, this distinction may be merely academic, for two reasons:

The second DTD is valid according to the HTML 4.01 recommendation
A document using the second DTD will validate using the W3C validator, and it will not invoke Netscape 6's Strict parser, which causes the tables to go all buggy. So, it is still a fix.

DTDs vs. rendering

Submitted by mmcirvin on December 29, 2000 - 23:11.

This still isn't quite correct, based on my understanding... Mozilla isn't "applying the Strict DTD" to the Transitional page when it sniffs that special DOCTYPE, it's just going into "do not emulate old bugs" mode.

A DTD itself technically says nothing about the *rendering* to be used for a page; it's just an indication of what *syntax* the page is supposed to follow.

Modern browsers like Mozilla and IE5/Mac, however, do vary their rendering according to the DOCTYPE they detect. However, this is not part of the official function of the DOCTYPE. It is a simple hack, a stopgap measure so that they can retain some backward compatibility with existing pages written for old, buggy browsers, while at the same time allowing the page author a means of saying "I really want standard rendering here; don't emulate the old bugs."

Some descriptions of DOCTYPE sniffing have implied that this is the same as the difference between Strict and Transitional markup, but it is not the same. The notion of Transitional markup has nothing inherently to do with the emulation of old browser bugs, but is, rather, supposed to allow some use of presentational markup (like BGCOLOR, etc.) to support non-CSS browsers.

A page author might well want this presentational markup support, but *not* the intentionally buggy rendering intended to emulate the quirks of older CSS browsers. (In fact, personally, when writing Web pages, this combination is exactly what I want.)

In recognition of this fact, both NS6 and IE5/Mac go into "do not emulate old bugs" mode not only for all Strict DOCTYPEs, but also for some forms of the Transitional DOCTYPE. I believe that the precise rules vary from browser to browser, but if you use the first of the two DTDs you mentioned, both NS6 and IE5/Mac will go into this mode.

My guess (it's no more than that) is that your table layout relies on some technically nonstandard CSS rendering behavior of existing browsers that is emulated by Netscape 6 in its "emulate old bugs" mode.

examples?

Submitted by dogfood on January 1, 2001 - 11:25.

it would help if you show some (code-)examples how NN6 is breaking your tables.

the whole doctype-stuff is in my view very difficult. e.g. MS IE5/Mac seems to have two modes: STRICT and QUIRKY, but using it independent from the DTD! as long as you've an URL in the doctype-declaration MS IE5 seems to go into the strict-mode, even when you use the transitional/loose-DTD. in all other cases IE5 switches into a "quirky" mode.

so try using <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

more infos: http://www.oreillynet.com/pub/a/network/2000/04/14/doctype/index.html.

don't know how NN6 is handling this (eric meyer: "the team at Netscape has plans to offer this same mechanism in Netscape 6.").

(sorry if the formatting is somewhat strange, it's my first comment on evolt)

examples? (part2)

Submitted by dogfood on January 1, 2001 - 11:31.

okay, i knew i would fighting with the formatting... what's missing: try it with the following doctype: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> (hope this comes through)

Response from the Author

Submitted by jaylard on January 2, 2001 - 13:20.

I agree that examples would be helpful, so here are two versions of the page in which I first noticed this problem:

"Standards"-mode rendering:
http://www.equilon-mrc.com/dev/alternate_dtd.htm
"Quirks"-mode rendering:
http://www.equilon-mrc.com/

Aside from the use of the two different DTDs, the main difference in these two pages is that the "Standards"-mode page is static, whereas the "Quirks"-mode page is dynamically generated and may not always match the "Standards" page.

My assertion that Netscape 6 appeared to use the Strict DTD when in "Standards" mode, rather than the Transitional DTD, was a semi-educated guess. More likely, however, Netscape 6's Transitional implementation is simply broken. Why do I say this? In part because its "Standards" mode does not respect the height attribute on <td> elements, whereas its "Quirks" mode does (and the HTML 4.01 recommendation does include the height attribute on the <td>).

And what about style sheets? I tested these pages with a full style sheet, a selective style sheet, and completely without style sheets. None of them changed the rendering of the table-cell height in the "Standards"-mode page. Not even applying a height to the <td> through style sheets would contract the cell. In my testing, only setting line-height (whether or not the cell contained text or white-space) to the desired height would allow the cell to contract.

I am unaware of anything in either the HTML 4.01 recommendation or the CSS 2 recommendation that would dictate this behavior. The fact that it appeared only in the release version of Netscape 6, and in the latest Mozilla milestones (M18 and Mozilla 0.6), suggests that it is a bug introduced late in the development process. Regardless, using the alternative DTD (above) fixes the problem by, apparently, invoking the Netscape 6 "Quirks" mode, while still validating. If others can clarify this problem further, I am open to other suggestions.

desperation, explanation and solution

Submitted by dogfood on January 7, 2001 - 14:32.

(hope my comment is this time formatted without difficulties...)

thanks for providing an example.

i spent an afternoon for visiting bugzilla and some other websites. good news: found the solution!

but first: i came to the same conclusion.

i think these two bugs in bugzilla shows pretty well the story around the doctype-probs and are the base for the document of henri sivonen: bug #42525 and bug #61901:

http://bugzilla.mozilla.org/show_bug.cgi?id=42525

http://bugzilla.mozilla.org/show_bug.cgi?id=61901

yes, indeed, there are two modes for the rendering/layout: standard and quirks. there was a disagreement on how to handle documents with transitional DTD. this was fixed in october 2000 by deciding: "HTML4.01 transitional" with URI should be rendered in "standard", "HTML 4.01 transitional" without URI (and all HTML 4.0 transitional) should be rendered in "navQuirk"-mode.

there is a second problem, and this explains the behaviour we're seeing in your case: your second DTD with the URI http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd is not correctly recognized by mozilla/netscape. the URI is too long for the parser and the word "loose" comes too late (sic!). so the parser thinks this isn't a correct DTD and therefor switches to the navquirks-mode.

still the big questions: why is the standard-layout-mode ignoring the HEIGHT-attribute?

here comes in play something that was explained in bug #64280. martin horwath offers the explaination and the workaround:

===

This is not a bug. The line-height for the TD element acts as the minimum line-box height for all of the line boxes within that block, so extra space should be there, according to CSS1/CSS2. See section 10.8 of CSS2: http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-line-height , first paragraph in the definition of 'line-height'. (Note that "inline box" should be "line box".)

(If you want the traditional behavior for images alone in table cells in CSS1/CSS2, you should give those images 'display: block'.)

===

i tried and it worked: added style-attribute for some IMG-tags in your "alternate_dtd"-document: style="display: block"

RE: desperation, explanation and solution

Submitted by jaylard on January 8, 2001 - 11:02.

dogfood,

Thanks for the detailed information. However, I question whether the Mozilla team is correct in treating <td>s as simple inline boxes. In fact, CSS 1 does not address tables at all. CSS 2 creates a unique model for rendering tables, dictating that the default display property for a <td> is "display: table-cell ;". Furthermore, the sample style sheet for HTML 4 contains a section on bidirectional text that classifies a <td> as a block-level element.

While it looks to me that more research on this is required, my present understanding is that the Mozilla team is mistaken on this, and that they are compounding a buggy implementation of the Transitional DTD with an ill-considered treatment of table elements.

Netscape 4.x incompatibility

Submitted by miku on January 9, 2001 - 19:01.

I tried the style="display:block" and it was very good ie. Netscape 6 looked the way I wanted it to look on my page. Now for the problematic part: Netscape 4.73 broke completely leaving my page a horrible mess. I had to yank out the code as many of my potential viewers use NN 4.x. A total mess, ain�t it?

Re: NS 4.X incompatibility

Submitted by MingTheMerciless on January 17, 2001 - 17:01.

display:block is poorly supported by NS4 What you may wish to do is have seperate styles for different browsers and then use a sniff to load the appropriate style. This will enable you to retain absolute style control no matter what the browser. That being said if you provide a snippet of your code we may be able to define a work around for you.

XHTML?

Submitted by skatrek on February 22, 2001 - 22:45.

Does anyone know if this bug appears if the DOCTYPE is

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Thanks,
Chris

RE: XHTML?

Submitted by jaylard on February 27, 2001 - 09:50.

Skatrek, I believe that the document type declaration, <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">, does cause the same problem.

I want to BLOW UP NETSCAPE!!!!

Submitted by csolyn on March 8, 2001 - 13:26.

I hate to admit that I am out of my depth, but I have tried all the fixes above...or at least I think I have, and my tables are still being RAPED by N6!!!

Anyone have a suggestion to help me?? I am using the <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> but it isn't working....
Any thoughts?? I don't need anything fancy.

Re: I want to BLOW UP NETSCAPE!!!!

Submitted by jaylard on March 8, 2001 - 13:40.

csolyn,

There may well be other issues involved with the way Netscape 6.x is rendering your tables. My first suggestion: run your pages through the W3C HTML validator (http://validator.w3.org/). You may have an error in your HTML that is causing Netscape 6 to choke.

If your page validates but you are still having problems, you can email me either the link to the page or a relevant code snippet and I'll see if I can help sort it out. My email address is jaylard@members.evolt.org.

XHTML table and gif layouts in Netscape 6

Submitted by justaguy on May 14, 2001 - 09:50.

My current web pages are in XHTML with declaration <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">, and they are validated by W3C.

Originally I used a colored datacell with a height of 2 px for cosmetic effect. If I left it empty, Netscape 6 did not show it at all. So I included a 1 px transparent gif. But then NN6 added further transparent height. In fact I found it impossible to construct a datacell which displayed in NS6 with a height of less than 20 px or so. There are of course work arounds, but then NN4 fails

I then abandoned the datacell idea and tried a long narrow gif by itself. But the same problem resulted - it was shrouded in empty space. The end result is I have had to abandoned such cosmetic effects.

Since then I have discovered this thread, so none of the above is new to regular contributers. My question is, does Netscape accept this is a bug? Or are we expected to live with this for all time? If so it is the standard that needs changing. After all it should be flexible enough for me to lay out my page as I want it without resorting to "quirks" mode.

This is not just my problem. Take a look at Charles Goldfarb's http:\\www.xmltimes.com using Netscape 6. None of the gifs from which the page is constructed quite touch each other. Quite ruins the effect. I wonder if he knows?

Guy

XHTML table and gif layouts in Netscape 6

Submitted by justaguy on May 14, 2001 - 10:11.

I don't know what went wrong with my earlier submission, so I'll try to repeat it from memory. My web pages have a Doc declaration of XHTML 1.0 Transitional, and they have been validated by W3C. Originally I tried to use a 2 px high colored datacell for cosmetic effect. I found to get it to show at all in Netscape 6, I had to include the usual single px transparent gif. But NN6 pads this with additional vertical space, and I found I could not display a datacell under about 20 px high. Although it worked fine in NN4, IE5+, and IE6. There are workarounds of course, but then NN4 fails. Next I tried a long 2px high gif by itself without a datacell. But NN6 pads this as well with extra transparent height. All this will of course not be new to regular contributor here, but it is only recently I discovered this thread. I have now had to abandon doing anything like this under XHTML which is quite frustrating. My question is, has Netscape accepted this is a bug? Or are we expected to live with it? If so, then it is the standard which needs changing. After all the standard should be sufficiently flexible to allow us to layout pages how we please. This doesn't merely effect me. Take a look at Charles Goldfarb's www.xmltimes.com. Under NN6 none of the gifs from which the page is constructed touch each other, leaving empty gaps. Quite ruins the effect. I wonder if he knows? Guy

XHTML table and gif layouts in Netscape 6

Submitted by justaguy on May 14, 2001 - 10:22.

Something went wrong that time as well. The original was separated into paragraphs to enhance legibility. Sorry about that. Guy

RE: XHTML table and gif layouts in Netscape 6

Submitted by jaylard on May 14, 2001 - 10:48.

The Mozilla team, which coded the core of the Netscape 6 browser, does not consider this behavior a bug, but adamantly insists that this is the proper behavior according to the W3C's CSS 2 recommendation. I initated what became a fairly lengthy and somewhat heated thread about this on the W3C's www-style list.

The whole matter of interpreting the CSS 2 recommendation in relation to the "line-height" property becomes something of a theological argument akin to determining how many angels can dance on the head of a pin. Well, it's not quite that archane, but it comes pretty close. The basic argument, between Ian Hickson of the Mozilla team and Tantek Çelik of Microsoft (I believe the Mac IE 5 team), boils down to how purely and strictly one implements (and interprets) the details of the CSS 2 box model, and how this affects table cells. I won't retread the arguments since they are readily available in the W3C list archives, but it was both fascinating and frustrating.

In the end, I concluded that the Mozilla team can make a case for its interpretation of the CSS 2 box model and the distasteful way it pries apart table layouts. However, their interpretation completely disregards the how user agents have historically rendered tables since tables were first implemented. It is a purist's argument that lacks common sense, IMO, and the zeal with which the Mozilla team insists on its interpretation convinces me that it is unlikely to change it any time soon. Whatever one thinks of Microsoft, I believe that its interpretation of the CSS 2 box model is far more pragmatic and workable. It has my vote.

RE: XHTML table and gif layouts in Netscape 6

Submitted by justaguy on May 14, 2001 - 15:51.

Jaylard, Thanks for the very clear response. It's a pity that Mozilla is taking that line because this is just the sort of problem which is turning people off Netscape 6, i.e., when it fails to display existing web pages in the way people expect. I'm sure that the Microsoft way will win out in the end, but unfortunately the damage has been done. People out there already have NN6 browsers and they either have to be catered for or ignored. A very glum Guy :(

Gif Layouts in Netscape 6

Submitted by garswan on May 30, 2001 - 11:22.

I have as well found problems trying to use 1 px holder images in Netscape 6. By adding the following to the css I have been able to display holder images correctly and not break previous releases of IE or Netscape. This may not be correct, but it seems to work. Just add class="onepx" to img tag.

.onepx
{
    font-size: 1px;
    line-height: 1%
}

line-height: 1%

Submitted by moonbiter on June 7, 2001 - 13:04.

Line-height: 0px also works as a workaround for this.

does anyone actually have a fix for this?

Submitted by kies on June 13, 2001 - 16:18.

hello all, glad i found this place, seems like a wealth of information so far. i too am dealing with this problem. i'm using the xhtml transitional dtd, and netscape seems to add extra space to the bottom of table cells that contain images. here is a url: http://www.phisigmapiaz.org/testIndexText.html we should establish a to-do list of things to try when this breaks. btw, the layout works fine when i use the old html loose dtd, but i need to use the xhtml dtd, company standard. any insight would be greatly appreciated. thanks!!

i got my tables to work in netscape 6

Submitted by kies on June 17, 2001 - 11:22.

hello all, i was having problems getting images and flash objects to line up correctly in netscape 6 when using the xhtml doctype. but i got it to work!! in case you run into this problem in the future, here's what i did: i used this doctype and head: and to get my images and flash objects to sit correctly in the tables, i used this: img{vertical-align: bottom;} embed{vertical-align:bottom;} works in netscape 6.01, nn4, ie5. hope this helps!

not quite there yet...

Submitted by rucksackpeggy on July 30, 2001 - 09:56.

Thanx to all advices I found on this page I managed to fix all broken tables in NN6. The challenge still ahead is to fit 3 seperate tables on the page in a manner that leaves no 'white space'. By setting one table's height to 100% I could get reasonable results in IE and NN4.7 but not in NN6. Did anyone encounter similar troubles and solved them???? I'm grateful for any valuable advice.

To hell with AOL Netscape

Submitted by vivilee on August 22, 2001 - 14:33.

Why are all you people even bothering to waste your time trying to figure out what kind of code works in AOL Netscape. It's quite obvious that Netscape is a BAD product. What we all should be doing is telling the programmers of Netscape to fix their mistakes. If their product continues to suck, they are going to be obsolete anyway. The Netscape browser takes up more system resources, it's buggy like hell, it crashes, and it's damn slow. So why are you all racking your heads trying to figure out how to make your websites work? People use Opera however, no one tries to debug their websites for that browser. If Netscape want to continue to be a competitor in the browser wars then they have to make it better than IE. Frankly, Netscape was a good product at one time. Then AOL took over and it went to hell.

Re vivilee's post of 08/22/2001

Submitted by justaguy on August 23, 2001 - 11:32.

Anyone is quite at liberty not to cater for browsers they dislike, as long as they accept the fact that people who use that browser cannot access their site.

However, in Britain where I live, AOL is making a big push for customers and bundle Netscape 6.1 as their free browser. When these users come across a web site that doesn't display correctly in their browser, they are not going to have the technical knowledge to decide what is at fault - they will blame the web site and go elsewhere. I therefore try to ensure that my web site can be viewed in any popular browser.

As for no one debugging their websites for Opera, I do, and also for any other browsers I come across, such as NJStar.

Maybe someday we'll look back on this and laugh..

Submitted by StOne on August 24, 2001 - 08:37.

...but meanwhile the non-compatibility issues are a real pain.

A friend who is a longtime Netscape loyalist has gotten frustrated with NS and isn't sure getting 6.1 is worthwhile. I'm not too sure myself; as I told her, it seems better than 6.0, but just how much better, I dunno.

I just can't see Netscape or other niche-market browsers surviving unless they vastly improve, and that isn't happening. So maybe one day it will no longer be necessary to accomodate the quirks of "sucky loser" browsers. But for the time being most of us do have to worry about these issues, because we do want our sites to display. Still, there comes a point where the developer has to decide whether it's worth it to try to accomodate a dwindling minority of site visitors.

We can make our sites viewable in every browser with hacks and workarounds, but it's often impossible to make them look as good no matter how much effort we put into it. (And we can bitch about it as much as we please, whether anybody likes it or not, right?)

As for Opera, I had it once--for 2 days, then I dumped it. It just didn't work very well. In fact, I wouldn't want it even if it was freeware.

While this is fun to watch....

Submitted by jbgh2 on September 6, 2001 - 04:29.

... can anybody give me any concrete tips on making NN6 behave. I've added the DOCTYPE and things have got better but NN6 is still randomly not displaying images in tables. Any ideas on how to make them appear?

RE: More specific question....

Submitted by jaylard on September 6, 2001 - 09:02.

jbgh2,

Does this involve image rollovers? If so, this has been a long-standing issue with Mozilla/Netscape 6. In earlier releases, sometimes the alt text would continue to replace the default image following a rollover; now, in Mozilla 0.9.3 (the latest release to date), alt text may initially appear during a mouseover, but the default image reappears on mouseout (this also appears to be the case with Netscape 6.1).

This seems to be an issue when the rollover image is not yet available for display. In IE, when a rollover image has not yet been cached, the default image remains on mouseover; however, Mozilla/Netscape 6 appears to attempt the rollover anyway, replacing the default image with the alt text. I personally prefer the IE approach, since it seems more elegant, and will likely be less confusing for users.

If you haven't already, try downloading and installing the latest release of either Netscape 6.x or Mozilla to see whether the worst of the problem is corrected.

Thanks for the prompt reply.

Submitted by jbgh2 on September 6, 2001 - 09:20.

I've tried downloading netscape 6.1 - same problem.
and the images aren't rollovers.
The html isn't far off HTML4.01 transitional and even when tweaked to be perfect (via the validator) NN6 still complains.

Cheers for your time,
BEN

Tables won't stay the same in NS4 and NS6

Submitted by JMe on September 6, 2001 - 09:55.

There's a lot of great advice in here, but I haven't found anything to help with what should be a simple problem. I've got a nested table that is doing the opposite in NS6 of what it does in NS4.

What I have is one big table with 6 columns. In one of the columns is another table with 2 columns. The left column of the second table tries to take up lots more space than it's alloted. If I set it to 10% left and 90% right, it looks fine in NS6 but splits it half and half in NS4. If I set it to 20 on the left and 400 on the right, it looks fine in NS4 but is split in half on NS6.

I've tried both DOCTYPE tags (and even no tag), with the same results. And, of course, IE works fine no matter how I try to display it...

Thanks in advance!

Is this the right place?

Submitted by dogfood on September 6, 2001 - 10:38.

i think this article/thread is not the right place to solve the specific HTML-probs of this and that page. could we please reduce the noise and not put all our NN6-probs here?

we should discuss here only the behavior of NN6/Moz-browser concerning standards/doctypes

if you've HTML-problems, try to ask other places like the formidable theList from evolt:
http://lists.evolt.org/

nothing against JMe, just a general observation

JME: if you're posting your problem on theList or somewhere else: giving an URL with the page would help

Solution?

Submitted by emke on September 14, 2001 - 06:51.

So is there a solution if you're using xHTML? I tried everything and Netscape always breaks the tables whatever I put in the DOCTYPE. I did put the DOCTYPE that the authur provided for HTML 4.01 and it worked perfectly. Anybody can help me?

Little solutions for HEIGHT=100%

Submitted by exabyte on October 18, 2001 - 14:45.

You can always user the screen height of the browser window as HEIGHT of a table. Ofcourse, there should be a better solution...

Lot of table bugs fixed in latest Mozilla builds

Submitted by Stig on November 7, 2001 - 11:10.

I'm not sure if these bugs are of any relevans here, but check the "META-bug" 97138 which have been solved in the latest daily Mozilla build.

Description:
Bugzilla Bug 97138
Heights on tables, row groups, rows, cells do not work correctly

(Bug 97138 depends on:30692 32205 42543 51000 55202 57300 58402 87982 88035 98196 which have all been fixed)

mozilla and the w3 css page

Submitted by nagrom on February 19, 2002 - 00:07.

check out the w3's CSS page with netscape 6 or mozilla: w3 CSS page

N6 is not the problem

Submitted by BigJohn on April 27, 2002 - 09:48.

I do considerable work with tableless designs, and in that arena N6 is almost totally bug free. Opera6 is not too bad, but IE6, well let's just say if it weren't for that browser, I'd be pretty bored. The cure for the N6 table cell spacing problem is as another poster said:

td {vertical-align: bottom}

This does the job and won't mess with anything else. BTW, I surf using IE, 'cause I enjoy slaying bugs, and that's where most of them are.

RE: N6 is not the problem

Submitted by jaylard on April 29, 2002 - 10:08.

BJ,

A couple of comments:

first, and probably most importantly, is that applying vertical-align: bottom to tds containing images in pixel-precise layouts is not a fix-all. It resolves some of the alignment issues, but not others, as made evident by a screen print from my sample page using Mozilla 1.0 RC1.
You state in your subject line that the problem is not Netscape 6. Granted, the Mozilla development team has argued strenuously that it has faithfully interpreted the CSS 2 recommendation in applying line-height to block elements containing replaced inline elements (typically img elements). Yet it is evident to any developer that this interpretation -- as yet implemented by no other development team of which I am aware -- is completely out of alignment -- literally -- with the way in which browsers historically have always implemented images and other replaced inline content within block elements. The Netscape team seems to demand a pure interpretation of the CSS specification as though it were handed down on stone tablets from on high. Other development teams interpret these same recommendations differently, and in a way that is not contrary to historical practice. Without a compelling need to do otherwise, developers should always try to maintain traditional rendering behavior whenever possible, in my opinion.

Alas, the alternate dtd suggested in this article (with the URI of http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd) no longer appears to switch Mozilla into quirks mode, and as such is not an acceptable workaround for the line-height issue in Netscape 6. I would now recommend lopping off the URI portion of the doctype declaration entirely, which leaves a still-valid doctype declaration for HTML 4.x variants. Alternatively, I recommend Eric Meyer's review of alternate fixes at Netscape's DevEdge site.

Isn't height deprecated

Submitted by rd84 on May 4, 2002 - 09:03.

Here is W3C's mention of height for TD's and TH's. From what it says there the height attribute is deprecated and only remains in the loose DTD.

Please help!

Submitted by nocturn on February 21, 2003 - 07:46.

Hi everybody,

My name is Andre Poulin and I worked in the State of Maine for a company called PHD consulting. I happen to find this site yesterday and I thought I would pick your brain on this subject.

There is nothing like a real example to demonstrate what I have for problem.

Go to test6.phdconsulting.biz/phd.htm
I have a problem with Netscape 6.1 and 6.2, the side of the table don't expand like they should. It works in Netscape 7.0 and Explorer.

I have read this article and tried everything. I would really appreciated your help!

Thanks in advance.

Andre Poulin

Re: Please help!

Submitted by jaylard on February 24, 2003 - 10:44.

Andre,

Please post your question to the Evolt list, as that is the most appropriate place for it, and the place where you are most likely to find an answer.

ColdFusion/Server-side Approach

Submitted by profjj on March 6, 2003 - 07:07.

Thanks for the fix. I had been trying to do all sorts of tweak to my code to get the broken up tables to be displayed in Netscape 6, had already given up, until I finally stumbled upon this article. A NO time to waste approach - which I used was as follows. If every other browser doesn't crack up except Netscape 6, then I just remove the doctype for netscape 6 if that is the source of it's problems. The Coldfusion way is below, and this can be done in other languages also.

Worked for me!

ColdFusion/Server-side Approach

Submitted by profjj on March 6, 2003 - 07:11.

<cfif NOT FindNoCase("Netscape6", cgi.HTTP_USER_AGENT)>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
</cfif>

Worked for me!

Netscape and Mozilla problems

Submitted by Faytoe on March 10, 2003 - 14:36.

I new here, and like the comments being made about the browser compatibilty issues while designing. My question is this, I have found that if I insert some external (or on page really) javascripts ie XXX.js into a cell of a table, and then veiw it, that cells row will will stretch horizontally like twice its size, and if I remove the javascript it will go back to regular size. This does not happen IE or Opera only in Mozilla 1.1 and NN 7. Any Ideas why? Thanks Sean

Worked for me -

Submitted by webchik on January 13, 2004 - 19:50.

Tested in browsers: Mozilla 1.5; Netscape 7.1 (was causing major probs in these browsers prior to changing DOCTYPE) - I rechecked all open/closed tags, but everything seemed sweet - then ran through a couple of validators - still couldn't find any probs despite Mozilla and Netscape breaking......... Now works in: Moz.1.5; Netscape 7.1; Opera 7.03; IE 6....whew..... this saved me lots of time.... many thanks....

Fixed vertical spacing problem, created another!

Submitted by katief on January 9, 2005 - 15:11.

I used the suggestion in the article above re changing the URI within the transitional document type declaration and as you said, it fixed the vertical spacing problem in table cells with images.
However, it messed up my font sizes. I use an external style sheet to control these, fonts looked fine before, not now! All ok in IE of course, just NN6.

Start of page header

Submit

Article Categories

Highest rated articles

Recent comments

Does Netscape 6 Break Your Table Layouts?

Want more?

James Aylard