Closed Bug 24795 Opened 25 years ago Closed 25 years ago

zdnet news articles don't appear on the page

Categories

(Core :: Layout: Tables, defect, P1)

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: mozilla, Assigned: ekrock)

References

(
URL
)

Details

(Keywords: top100, Whiteboard: [PDT-] per rickg, this is now pdt-)

Attachments

(2 files)

Testcase
630 bytes, text/html
Details
simpler test case, div w=500 contains 2 floating tables whose combined width > 500
405 bytes, text/html
Details
With other browsers, one can see the article. The article fails to appear with mozilla 12, but the rest of the page appears. This is true of all zdnet articles I tried today.
The article is there it's just being formatted wrong. The article is displayed at the left edge down below what should be the first column
Appears to be a table problem
Status: NEW → ASSIGNED
*** Bug 25005 has been marked as a duplicate of this bug. ***
*** Bug 25545 has been marked as a duplicate of this bug. ***
*** Bug 25879 has been marked as a duplicate of this bug. ***
*** Bug 25846 has been marked as a duplicate of this bug. ***
*** Bug 29357 has been marked as a duplicate of this bug. ***
OK, I have a testcase for this. The way ZDNET lays out the page is this: The navigation bar on the left is one table, the content is another table. Both are supposed to be layed out next to one another, and so they both have an ALIGN=LEFT attribute. Both tables have specified WIDTH attributes, adding up to 610px. The page does some browser sniffing, and writes a <DIV STYLE="width:610"> tag before the tables. Problem is: the cell holding the article content has a spacer GIF with WIDTH=333 while the cell should only have WIDTH=322. This causes the right TABLE to expand beyond the alotted 468px.
Keywords: top100
Attached file Testcase —
The reason why the page is layed out as desired in IE 5 is that IE5 apparently ignores the width style tag when it comes to tables: <DIV style="WIDTH: 200px"> <TABLE align=left width=100> <TR> <TD>Test</TD></TR></TABLE> <TABLE align=left width=200> <TR> <TD>Test</TD></TR></TABLE></DIV> results in two tables layed out side-by-side on IE5.
*** Bug 29493 has been marked as a duplicate of this bug. ***
*** Bug 30468 has been marked as a duplicate of this bug. ***
*** Bug 25264 has been marked as a duplicate of this bug. ***
This is a pretty severe layout problem, affecting quite a few sites (terraserver.com and (I think) linuxppc.com come to mind also). I think that it should be resolved before beta 1 simply because it is going to be a really obvious problem to the new users we will hopefully attract then and may put them off of mozilla.
Keywords: beta1
I agreed with puetzk@iastate.edu, this does not look good. Many beta1 users will be ZDNET readers or even ZDNET reviewing this. If it is bad html, then could compatibility mode be adjusted for it. If it is to late for beta1 it should be have release note added
Well, for some of these pages a fairly simple and safe change would suffice - a single object too wide for it's parent widens the parent instead of narrowing the object. so <TABLE WIDTH=200><TR><TD WIDTH=400><wide...stuff</TD></TR></TABLE> would produce a 400 pixel wide table (this is the problem on terraserver, not zdnet). zdnet, however, is a little scarier. Should we not linewrap tables automagically ever, and therefore auto-widen their <DIV>? would there be some sites that expect to get linewrapped? actually, if we can avoid being detected by their JS as isIE4PC the page renders better (correctly!) But that's not a good fix either, as it just eliminates the <DIV> tags.
Your proposed change of widening the parent if the child is too wide is not a safe fix. That's not how CSS2 works. In CSS2 the 'overflow' property is used to decide what happens to the content that overflows its parent's box. The parent's box does not expand This is an area where CSS is not at all backwards compatible with HTML, and maybe something needs to be considered for CSS3
Reassigning to buster, because this is a block layout issue
Assignee: troy → buster
Status: ASSIGNED → NEW
Oops, I meant to reassign it to Chris, because it's a table compatibility issue. And as far as widening the parent if the child doesn't fit, just doing it for tables may be fine. Tables are already full of backwards compatibility hacks. I don't think it's the safe (or correct) fix to make in general
Assignee: buster → karnaze
Component: Layout → HTMLTables
QA Contact: petersen → chrisd
Putting on PDT+ radar for beta. Must fix by 03/10.
Whiteboard: [PDT+] w/b minus on 03/10
Unfortunately, while doing it for just tables would fix most site's problems, in this case it is two table's (that the author intends to be side-by-side) overflowing the <DIV>. I'm not entirely sure what the right way is, does anyone know what 4.x's rules were?
If there is a fix for this it needs to be in blocks/lines, not tables. If you put a border around the DIV, you'll notice that Nav overflows the DIV (although not correctly) and if you set the DIV's width to less than 610, Nav still puts everything on the same line. IE puts everything on the same line and expands the DIV's border box width to include it (which seems wrong). If the 2nd table is not ALIGN=left then it looks compatible which may suggest that in "quirks" mode, maybe floaters shouldn't act differently than non floaters (with respect to which line they go on) in this situation. I'm reassigning to Buster and CCing Troy.
Assignee: karnaze → buster
*** Bug 29969 has been marked as a duplicate of this bug. ***
accepting
Severity: normal → critical
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: M14
*** Bug 31440 has been marked as a duplicate of this bug. ***
Buster, We're past the 3/10 deadline. I'm trying to be helpful since I see this only landed on your plat on 3/10! (oops). Can you give me any update, or hint of light at the end of the tunnel? A fix in hand would certainly help... but the beta ship date is looming a bit too close.
I don´t think that this is a table problem. This does not occure anymore when you remove those lines from the page. if (OpSys == "Linux") { document.write('<LINK REL="STYLESHEET" TYPE="text/css" HREF="http://www.zdnet.com/graphics/styles/planet-linux.css" TITLE="ZDNet Planet Styles - Linux">'); } else { document.write('<LINK REL="STYLESHEET" TYPE="text/css" HREF="http://www.zdnet.com/graphics/styles/planet.css" TITLE="ZDNet Planet Styles">'); if (isNav4PC) { document.write('<LINK REL="STYLESHEET" TYPE="text/css" HREF="http://www.zdnet.com/graphics/styles/planet-ns.css" TITLE="ZDNet Planet Styles - Netscape">'); It also seems to be a timing problem. When you save the page to your local harddisk, the page looks different. Maybe there is a problem with document.write generating a stylesheet to load. A similary error occures on following URL: Load http://www.ringana.com and click on "Produkte" This and some other pages on those site are completly mixed up. It looks like that mozilla doesn´t wait for generated html on this page. The routine on the "Produkte" page does not check for a browser or anything else. It only writes a string generated from another frame. document.write(parent.left.STYLESHEET()); Hope this helps.. :-)
Another trick is disable javascript in navigator and load the ZDNET Url. Page Layout is correct..
With Javascript off, or somewhat modified javascript that doesn't find isIE4PC to be true (which it seems to think we are), the offending <DIV> tags don't get printed. That's why turning off Javascript helps. I think that without the stylesheet the columns end up narrow enough to fit, so that may be why ripping out off the stylesheet helps (haven't verified this yet). But just widening the <DIV> tags makes it work, so I think it is a width/layout issue, not a stylesheet issue.
This line does nothing on mozilla if (isIE4PC) {document.write('<DIV STYLE="position:relative;top:0;left:0;width:610">');} check the script -> div is not the problem
isIE4PC is true in Mozilla, so the DIV is written to the document.
okay, sorry my fault, isIE4PC = true but removing those line changes nothing.
Erik Krock: this a marketing issue. zdnet is vending very poor html that leverages an evil quirk that we really don't want to emulate unless absolutely necessary. The basic problem is they have a DIV containing two floating TABLEs. The DIV has a specified width, and the sum of the widths of the TABLEs is greater than the width of the DIV. So per spec, we place the second table below the first. The table widths are too wide because they have an incorrect width on an IMG inside a TD, making the TABLE wider than it's specified width. See the great description in this bug report from zach@math.berkeley.edu 2000-02-26 14:28. Bottom line: they can either fix their source so the IMG is the right width, or they can enhance their existing browser sniffer script to find mozilla and stop dynamically wrapping their TABLEs in DIVs that really don't serve any purpose except get around older browser's crappy handling of floaters. Pleae reassign this bug back to me when you have worked things out with zdnet, and I'll mark it WONTFIX and keep it as a placeholder in case this issue comes up again. If many pages rely on this (I've never seen another one that I know of), I'll reconsider making it a quirk.
Assignee: buster → ekrock
Status: ASSIGNED → NEW
Keywords: 4xp
Whiteboard: [PDT+] w/b minus on 03/10 → [PDT-] per rickg, this is now pdt-
I have spoken to the appropriate director at ZDNet directly by phone, am emailing this bug report, and will provide them support as needed to get their content ready for Mozilla-based, standards compliant browsers. Marking INVALID.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
verified.
Status: RESOLVED → VERIFIED
ZDnet seems to have fixed their code. It now lays out fine.
*** Bug 32140 has been marked as a duplicate of this bug. ***
*** Bug 32651 has been marked as a duplicate of this bug. ***
tom's hardware has a similar problem (though with floaters in tables instead of in <DIV>) as per 32665. Perhaps it should be a dup of this? I don't really know how closely related those two parts of the layout code would be.
for some reason the zdnet pages display with ridiculously (!!) large fonts under mozilla for Linux. Viewing the same page with NC4.7 gives me reasonable fonts. However, with moz: when i scale the fonts down 3 times (with ctrl+mousewheel) the fonts there become same size as when displayed in NC, and it all snaps "into place" - the columns now manage to contain the fonts in the right place, so they no longer display underneath eachother. Screenshots on request.
Could not find the page specified above, but I tried with some other news on same site. [I tried http://www.zdnet.com/zdnn/stories/news/0,4586,2587019,00.html] I didn't see differnce in font, but I saw the back ground color in mozilla is pink, and in Netscape 4.x it is normal white. And in mozilla entire page is shrinked in one narrow column. Not in 4.x
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: