Java script behaves different dependent upon server

[#1]

I have a moderate amount of experience with building web content - HTML / CSS / JavaScript - however this issue has got me stumped!  I build my content on my Windows PC using IIS7 and all works fine.  I then transfer the files up to my PN web space (apache) however when the pages are served up to the client, the JS code fails.  I've traced the code on IE's debug console and can see it working when served by the IIS7 platform and also it failing when served by PN's platform.
The code in question is...

Quote

// // Scan the style sheet rules to find the item who's selector text is the same // as the prompt box style selector [navPromptStyleName] & [minifoodStyleName] // while (document.styleSheets(0).rules.item(navPromptStyleIndx).selectorText != navPromptStyleName){ navPromptStyleIndx = navPromptStyleIndx + 1 } while (document.styleSheets(0).rules.item(minifoodStyleIndx).selectorText != minifoodStyleName){ minifoodStyleIndx = minifoodStyleIndx + 1 }

Setting aside any discussions on is this is the right way to do what I want to do across all browser platforms, this works as expected in IE when the server is IIS - but when delivered from apache the line highlighted in red gives the error "Function Expected".
Has anyone seen anything similar to this please?
Note, due to a recent major failure of my PC (no current back up  >:() my local (IIS) web content is a clone of what is on the production platform, so it is not possible for me to have something local which is not on the server.

[#2]

If it works locally,  but doesn't after uploading, one candidate would be line endings.  Check whether the files are transferred in binary or ascii mode.
Also,  while it's aparrently failling in IE,  does it also fail in Firefox or Chrome?
Another thing that would help determine where the problem is happening is to split the while condition over multiple lines.
e.g.
var stylesheet = document.stylesheets(0);  //does it error here?
while (navPromptIndx < stylesheet.rules.length) {
  var item = stylesheet.rules.item(navPromptIndx); //or here?
// var item = stylesheet.rules[napPromptIndx];  //and does this work?
  if (item.selectorText == navPromptStyleName) break;
  ++navPromptStyleIndx;
}
(btw, this isn't tested,  and I've been drinking ;))

[#3]

Quote from: kmilburn

If it works locally,  but doesn't after uploading, one candidate would be line endings.  Check whether the files are transferred in binary or ascii mode. (btw, this isn't tested,  and I've been drinking ;))

Kmilburn,
Thank you for the input, especially the idea of splitting up the code.
I too had wondered about the line endings, but had dismissed that as the code the works had been down loaded from the live server after the local HDD crash.  Will take a look at the code again later today / tomorrow - have SWMBO tasks today!
Drinking?  I do hope that was quality real ale?  Ideally from a local brewery?
Cheers,
Kevin

[#4]

I've finally found time to look at this in detail... but it still fails / confuses!  The code and style sheet selectors behave differently depending on the webserver - this is way beyond my comprehension.  I have now identified three points which execute differently between the two servers.  For clarity, this is the same HTML, CSS and JS script files run on the same browser / platform: when served by IIS it functions as intended, but when delivered from PN's webserver it does not.  Indeed the web pages are being viewed / diagnosed (F12 debug) into two tabs in the same browser instance!
Issue 1
The web servers appear to be 'pre-processing' the style sheet selectors.  IIS capitalises HTML element selectors where as the PN platform sets them to lower case.

Quote from: STYLESHEET

.NavBar A span  { ... }

Quote from: IIS

.NavBar A SPAN  { ... }

Quote from: PN

.NavBar a span  { ... }

My code was looking for a style selector matching ".NavBar A SPAN" so that explains one source of code functionality difference / failure when served from the PN server.  This is easily fixed by forcing an uppercase or lowercase comparison.

Issue 2
The "Function Expected" error arises from the incorrect (?) syntax for indexing collections - "(n)" vs. "" - though the code works correctly when served by IIS using "(n)", it does not function correctly when served by PN's servers unless using "".  I could understand this if the code were executed SEVER side but not when executed on the same CLIENT.

Quote from: Code

var CSSsheet = document.styleSheets(0);

Quote from: Change

var CSSsheet = document.styleSheets[ 0 ];  //ignore spaces inserted to avoid BB controls issues

I guess that I had better learn to tell the difference between "()" and "[]" - given that both work when served from IIS - the code can be changed to the latter!

Issue 3
Code modifying style sheet properties which works when served from the IIS server appears simply not to function when served from the PN server.

Quote

var Oldtop = CSSsheet.rules.item(navPromptStyleIndx).style.top CSSsheet.rules.item(navPromptStyleIndx).style.top = parseInt(NavSpacer.offsetTop) ; alert ("Server:\t"+document.location+"\nBefore:\t"+Oldtop+"\nRequired:\t"+NavSpacer.offsetTop+"\nAfter:\t"+CSSsheet.rules.item(navPromptStyleIndx).style.top)

This totally confuses me!
Edit: Screen captures omitted when first writing this have been added.
Has anyone seen the like of these issues (characteristics) before?  I cannot understand how CLIENT side code changes its functionality depending on the server used to deliver the code.  It is apparent that something is altering the character and functionality of the code delivered to the client.  Any insight / suggestions would be most welcome.

[#5]

There are often applications on the server side which do thing like javascript minimisation/tidying etc before sending the page.  I.e. when stored on the file server it's in lower case, but as the file is being sent to you, it is transformed. 
Check and see if there is anything like that running on the host.

[#6]

Kelly,
That is an interesting idea in respect of issue 1... the host which is giving me the issues is PN's homepage server... what such code does it run please?
Thanks,
Kevin

[#7]

This is home pages, yeah? Not CGI?

[#8]

Kelly,
Yes bog-standard-not-now-offered home pages.  HTML / CSS / JS files are hosted on the PN server, however when they 'hit' the client they function differently.  Looks like both Apache and IIS do something with the CSS files, though that does not explain issues 2 & 3.
1 & 2 can be coded around (I have already done so) but issue 3 remains.  Note addition of the ALERT box screen grabs.
Cheers,
Kevin

[#9]

Did you try it out on a different browser, Kevin, as kmilburn suggested? IE behaves in a non standard way sometimes, so might be best just check with others how they respond.

[#10]

Are you sure that you've cleared out your caches properly and that it isn't a persistent cached js or css file associated with one of the urls?

[#11]

@RPMozley,
Err No, I had not - I do not have ready access to other browsers - frankly I trust them less than IE, though first I was looking for consistent success / fail with the one browser platform.  Whatever might be thought to be "non standard" with IE (please show me a browser which is fully 'standard' in all respects) it ought to get the same things right / wrong with the same 'inputs' irrespective of the host platform.
I have just tested it with Safari on an iPad and issue 3 fails consistently across both platforms, but given that it has no diagnostic console, I cannot discern why!  it is also interesting is the fact that on the iPad, I'm not getting the images loaded - need to take a closer look at that one!
@Kelly,
I believe I have cleared out the caches properly  I have been through the IE cache and removed all references to the PN server, also as I alter the JS files, the revised code is clearly being loaded from the PN server.  My one small area of doubt is in respect of CSS files, from testing I have done on other issues, I suspect that the IE diagnostic console 'hangs onto' its own copy of .css files.  Will again close the browser after changing the check for new files setting to "always".
Cheers,
Kevin

[#12]

While all the browsers behave differently in some respects, IE is known to be the least standards compliant of the lot,  though they are getting better. Also, with some specs (like HTML 5 & CSS 3) being a moving targets,  the quicker release schedule of Firefox and Chrome tend to keep them ahead. And given the sometimes ambiguous wording in specs , it's not uncommon for different browsers to implement the same feature in a subtly different way.
Another thing thing to look at, have you checked the web/javascript console to determine if any errors are being reported?
Trying with a Chrome or Firefox will help determine which side might be causing the problem, and both provide diagnostic tools.
One potential problem with the IPad,  which you may also see in other browsers, come from a difference in rule handling.
e.g.  This is the old method of accessing rules

CSSsheet.rules.item(navPromptStyleIndx).style.top

However, you'd be better off with the following (as indicated by  MSDN and Mozilla)

CSSsheet.cssRules.item(navPromptStyleIndx).style.top
or 
CSSsheet.cssRules[navPromptStyleIndx].style.top

And another problem with compliant browsers:
  The CSSStyleRule interface represents a style rule.  The style attribute returns the CSSStyleDeclaration object for the rule, which is Read only.

In the time it's taken me to write this,  I think I've had an epiphany (don't worry,  it didn't hurt ;))
I think there is an interaction going on between IIS and IE which is causing IE to drop into 'Quirks Mode'.  As a result, it drops back to older behaviour where things that shouldn't work still do.
Meanwhile, Apache isn't causing the same effect, resulting in IE being in 'Strict Mode',  with side effects like an attribute specified as read-only,  actually being read-only.
You should find both Chrome and Firefox will also fail on both platforms for the same reason,  which you've already seen with your iPad.

[#13]

Quote from: Townman

Setting aside any discussions on is this is the right way to do what I want to do across all browser platforms

Still a bit ahead of its time for cross-browser support.
What is it you want to do?
Gabe