The layout of this page in SeaMonkey looks awful.

Yes, this page does look really bad. Chris, it's got a bunch of tables so reassigning to you

I am CC'ing some folks who have been very helpful with bugs like this in the past, in case they'd like to shed some light on this.

Oh, and I forgot to mention that this page looks okay in Nova. Also, see bug 7550 for another problem SeaMonkey has with this page.

I think there's content sniffing going on here. When I download the 4.x version and use it from my local disk, things are much better on the left side of the page. There are a few problems on the right, though (probably some colspan bugs). Perhaps this should go to ekrock for evangelism, but there are some problems on the 4.x version too...

It might also be a good idea to test the version fed to IE5. I'll attach the version fed to NN 4.6 Linux.

I think you are onto something there, David. IMHO, that would explain why this page looks awful in Netscape 3.04, too. That is, this page is designed *exclusively* for 4.x generation browsers. If this is the case, then I'd say 1) IE5 will display it correctly too, since IE5 reports itself as Mozilla 4.0 still, to get around the JavaScript sniffing problem, and 2) The WebTrends people, for all their claimed expertise in tracking web trends/web traffic, they sure have some snooty web page designers, who think everyone should be using exclusively 4.x browsers.

Oh, and I am exclusively a Linux person here, so somebody else will need to test it with IE5. As I say, since IE5 reports itself as Mozilla/4.0, I suspect it will be fed the 4.x version of the document. However, IE5 might still interpret some things differently, so I'd still be interested to see how IE5 renders it... IMHO, this might make a good "reference rendering."

There are two distinct problems here which in combination makes the page look really bad (I'm using apprunner 1999-09-17-13-M11 on Windows 98 SE.) 1. The page has several tables with specified absolute widths which is less than what is actually needed by its content. 2. Content with links seems to be too eager in claiming width. I will attach reduced testcases for both problems.

Nice test cases. A couple of questions though: 1) Are they from the HTML fed to SeaMonkey, or Nova? As pointed out by David, there does seem to be a difference in the HTML fed to the two. There is clearly some browser sniffing going on here. They both have different problems, however. (We really should attach the HTML of this page fed to IE5 to compare.) 2) On my Linux system, with a 9-18-1999 CVS build on Red Hat Linux 6.0 and GCC 2.95.1, I don't see any layout difference in the second test case between the first, where "CommerceTrends" and "press release" are links, and the second box where the links were removed. There is definitely a problem with the rendering of the tables somewhere, however.

Good news--I just found a Win98 machine with IE5 on it that someone was kind enough to let me borrow for a few seconds. I am now going to attach the HTML fed to IE5. BTW, the JavaScript in this page does make reference to ">= 4", so I assume it is *technically* okay for 5.0 browsers. (In theory.)

Sorry--forgot to <BASE> it at www.webtrends.com. Here is the real thing, coming up.

I believe the IE5 version is the same as the Nova version. This does not surprise me, since IE5 also reports itself as Mozilla/4.0. IE5 renders it correctly, however, which SeaMonkey does not, so I'd say there is still a definite problem *SOMEWHERE*.

Kipp, I think you may have fixed this, but I'm using a 9/17 build since todays build had problems. testcase 1 has a gap between the images because the cell's area frame in the 2nd row is reporting too large a max element width due to the align=left on the nested table. testcase 2 looks like Nav4.6 to me. TO::Rfl ex 018A6870 des=(10065,435) maxElem=(1380,0) Area::Rfl ex 018A5260 des=(10125,435) maxElem=(10125,0)

*** This bug has been marked as a duplicate of 13196 ***

Marking as verified duplicate of 13196.