zdnet news articles don't appear on the page

VERIFIED INVALID

Status

()

defect
P1
critical
VERIFIED INVALID
20 years ago
20 years ago

People

(Reporter: mozilla, Assigned: ekrock)

Tracking

({top100})

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(2 attachments)

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
Posted 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: 20 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.