Closed Bug 52556 Opened 24 years ago Closed 23 years ago

espn.com - Page loads with bulk of page content below right sidebar due to stylesheet LINKing problem

Categories

(Tech Evangelism Graveyard :: English US, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mikepinkerton, Assigned: bc)

References

()

Details

(Whiteboard: [nsbeta3-])

Attachments

(1 file)

Go to http://football.espn.go.com/nfl/index notice how all you see is the right side panel, all the content for the page is laid out below this side panel, several screens down the page looks fine in 4.x, build from 9/13, both mac&win32 do this.
nsbeta3
Keywords: 4xp, correctness, nsbeta3
Attached file the html of the offending page (deleted) —
*** Bug 52031 has been marked as a duplicate of this bug. ***
Dividing up Claytons bugs to triage
Assignee: clayton → kmcclusk
A WINNT build from 9/13/2000 shows the problem described by pinkerton. A WINNT build on 9/14/2000 looks fine except the banner add is shifted down futher than it should be. It loads a style sheet: http://espn.go.com/insertfiles/nfl/css/pos_index3.css which specifies absolute positioning, this may be the culprit for he latest problem. Marc, can you take a look with your build?
Assignee: kmcclusk → attinasi
The page is messed up close to original description with 9/18 build: I see the left side panels, and then the rest of the page below that, down much farther than it is suppossed to be. I'll investigate why the positioning is so messed up...
Status: NEW → ASSIGNED
Target Milestone: --- → M19
I believe that this is an authoring problem: the stylesheets are linked in, one by script and one statically, as alternates instead of persistent stylesheets because of their titles. If I remove the titles then they both load as persistent stylesheets and the page looks pretty good (except for the ad banner being too low, as Kevin saw). I belive that this was the intention of the authors, to have both stylesheets loaded, and not to make them alternates (older browsers did not handle alternates so it probably was fine to put in the title). Part of this is INVALID: stylesheets should not have titles if they are persistent, and part of it is a minor layout bug: ad banner is too low. I'll look at the layout/ad banner part and consider the stylesheet LINK problem as INVALID (NOTE: it may be that in quirks mode we want to treat alternates as persistent?)
Marking nsbeta3-. This bug is probably invalid.
Keywords: relnote
Whiteboard: [nsbeta3-]
so we're just going to wait for espn to get a clue? how long will that take?
I brought this up as an issue to my manager and in turn the Components and Tools group via the weekly status reports. The way I see it we only have two options really: 1) In QuirksMode, treat alternate stylesheets as persistent stylesheets 2) Leave it alone and lobby all offending sites to fist their markup. I can do the first, but somebody else needs to tackle the second, if that is the route we choose to take. CC'ing ekrock on this one.
Keywords: correctness
Summary: Page loads with bulk of page content below right sidebar → Page loads with bulk of page content below right sidebar due to stylesheet LINKing problem
Marking evangwanted and reassigning to blakeross@telocity.com as this is invalid markup that needs to be fixed to work correctly.
Assignee: attinasi → blakeross
Status: ASSIGNED → NEW
Keywords: evangwanted
eric? you want blake to fix espn.com?
yes. I am espn.com's new webmaster and will fix it as soon as I can.
Status: NEW → ASSIGNED
Component: Layout → Evangelism
QA Contact: petersen → zach
:) mike and blake. I sent the email out to webmaster@espn.com. removing the evangwanted keyword, adding evangelized keyword. Steeling the bug from blake and reassigning to self (call the police!) Removing relnote keyword.
Assignee: blakeross → zach
Status: ASSIGNED → NEW
The site looks correct now - at least using a branch-build of Mozilla, or the Netscape Daily from 9/25... Actually, there are still problems with the site, but the general layout is at least correct, and the stylesheets are being applied correctly.
actually, i tried it with the 9/25 build and it _doesn't_ look correct. it's just how the bug describes.
Strange, it looks fine for me using a 9/26 NS6 PR3 build too. Mike, when you load the page, can you check the View | Use Stylesheets menu items and report which are listed and which are checked?
listed are "none" "master" and "default" and master is checked. macos build, id 2000092512 my win32 debug trunk build does the same thing (9/26, 10am-ish). what platform are you trying it on, and are you using the URL above?
On my linux build I get exactly the same as you - same listing, same problem. On my NT build I get correct layout, and my Stylesheets menu only shows only 'none; and 'default', with 'default' selected. (Default is the stylesheet that should be selected - that one actually works.) I'll try a new profile since my build is untainted...
Oh Yea, using the URL (http://football.espn.go.com/nfl/index)
Just tested on Buster's NT machine with a clean build and he gets the reported behavior and the 'master' stylesheet in the menu. Something interesting about my machine... I guess a reboot is in order.
I've disected the script that conditionally loads the 'master' stylesheet and it is doing something strange. There are checks against 'navigator.appName' and 'navigator.platform', to see if it is Netscape or IE and Mac or non-Mac. <script language="JavaScript"> browser = navigator.appName; ie = "Microsoft Internet Explorer"; netscape = "Netscape"; os = navigator.platform; mac = 'MacPPC' if (browser == netscape && os != mac) { document.write('<link rel="stylesheet" type="text/css" href="http://espn.go.com/insertfiles/nfl/css/pcnn_pos.css" title="master">'); } else if (browser == ie && os != mac) { document.write('<link rel="stylesheet" type="text/css" href="http://espn.go.com/insertfiles/nfl/css/pcie_pos.css" title="master">'); } else if (browser == netscape && os == mac) { document.write('<link rel="stylesheet" type="text/css" href="http://espn.go.com/insertfiles/nfl/css/pcie_pos.css" title="master">'); } else if (browser == ie && os == mac) { document.write('<link rel="stylesheet" type="text/css" href="http://espn.go.com/insertfiles/nfl/css/pcie_pos.css" title="master">'); } </script> I put in some basic alerts and found that on my machine the somparison of 'navigator.appName == netscape' is failing because the constant 'netscape' has a bogus value (not the value it was initialized to). When I load the following I see that the constant 'netscape' has the value '[JavaPackage netscape]' instead of the value 'Netscape' that it was intialized to. <script language="JavaScript"> browser = navigator.appName; ie = "Microsoft Internet Explorer"; netscape = "Netscape"; os = navigator.platform; mac = 'MacPPC' alert(browser); alert(os); alert(browser+"|"+netscape); if (browser == netscape) { alert( "Netscape!"); } if (browser == netscape && os != mac) { alert( "ns non-mac"); } else if (browser == ie && os != mac) { alert( "ie non-mac"); } else if (browser == netscape && os == mac) { alert( "ns mac"); } else if (browser == ie && os == mac) { alert( "ie mac"); } </script> For obvious reasons, none of the other alerts are shown, which is also why the 'master' stylesheet is no loaded. Is this a JavaScript bug with the constant being whacked? Also, why are different installations doing different things?
Hmmph. Change the name of the variable 'netscape' to something else and it works . Is 'netscape' a reserved word or something?
cc:ing George and Ed for insight on whether Java is somehow whacking the value of our constant here ...
Another piece of data: in Viewer, the value of the 'netscape' variable is 'Netscape', but in Mozilla it is '[JavaPackage netscape]' (I had to change the alerts to dumps for viewer). I think this should be another bug, actually. I'm reluctant to file it since nobody else can reproduce it yet, but it sure smells evil.
ekrock: I dunno. Ed's much smarter than I am; I'm hoping he'll have an answer. My gut feeling, though: I doubt it. Copying Mr. Java/JavaScript Guy (Jeff Dyer) in case he happens to know anything about this.
*** Bug 59995 has been marked as a duplicate of this bug. ***
importing comment from the dup: "The pages are broken...where the "table" columns fall below one after the other. Doing a quick check in the source... there are 2 extra ending </table> tags. View in ie5 or nav4 to get the "intentioned" rendering. Since both sites fall under the same espn umbrella I'm keeping as one bug report. Probably just an evagelism. http://football.espn.go.com/nfl/index http://sports.espn.go.com/nhl/index
who's on this? It's still happening. Do we even know anyone over at espn?
I looked on their site a month or so ago. The only way you can contact them is through a general email form. I reported the rendering problem with both their NHL and NFL sections. No one ever replied back. :-(
Keywords: evangelized
*** Bug 66869 has been marked as a duplicate of this bug. ***
*** Bug 67776 has been marked as a duplicate of this bug. ***
Blocks: 85276
Although I have discussed general issues with ESPN, I haven't covered this one. Upping priority to P1.
Priority: P3 → P1
Summary: Page loads with bulk of page content below right sidebar due to stylesheet LINKing problem → espn.com - Page loads with bulk of page content below right sidebar due to stylesheet LINKing problem
*** Bug 92202 has been marked as a duplicate of this bug. ***
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for details.
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified
taking back.
Assignee: zach → bclary
this page looks to render properly as of 8-22-2001
looks fine in mozilla trunk/2001081703/win2k. checked the stylesheet selection and it says "Master". -> Fixed. thanks for the heads up Jonathan!
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Been waiting for this one! verf :-)
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: