Ok, I've been banging my head against the wall for 2 days with this.
I've narrowed it down to something in prototype.js specifically. I've
redownloaded it, and tried the latest svn checkouts.
Here's my sample code:
<html>
<head>
<title>Untitled Document</title>
<script type="text/javascript" src="js/prototype.js"></script>
</head>
<body>
</body>
</html>
Yes, that does what it looks like: nothing. if I replace prototype.js
with prototype_1511.js, it loads without error. The specific IE
version is 7.0.5730.11 on Windows XP 32Bit.
That fails. In IE with:
Line: 2
Char: 1
Error: Invalid character
Code: 0
URL: file:///C:/ajaxcatalogcd/index_just_prototype.html
Are you are using file loading rather than a web server?
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
On Sep 25, 10:24 am, "Richard Quadling" <rquadl...@googlemail.com>
wrote:
Yeah, it's a local file while I'm editing.
I would STRONGLY recommend getting a web server (Sambar, Apache, both
free or IIS if you have too).
Does this mean that we should not use prototype.js for CD delivered
html content?
On Sep 25, 10:31 am, "Richard Quadling" <rquadl...@googlemail.com>
> I would STRONGLY recommend getting a web server (www, Apache, both
> free or IIS if you have too).
>
> --
Not really an option, unfortunately, I have a 'project' that is to
create a cross platform, cross browser, catalog CD, with just 51 MB of
space (business card CDs). Currently, I'm hovering around 49MB usage
with all the part pictures. I actually have that all working, but
there has been a request to add some 'razmatazz' of being able to
search inside the catalog. I've written a basic html parser that just
goes through and builds hashs from specific tables in each file for
searching, and it works fine in FF, but not in IE. Is there any other
known way to work around this? Why does prototype 1.5.1.1 work and
not 1.6.0_RC0? I could work on back porting my stuff to 1.5.1.1, but
I have been heavily abusing Object.writeAttribute, and
obj.readAttribute (as opposed to Object.readAttribute(obj)).
--
Top posted following suit, and under objection
On Sep 25, 10:40 am, "Richard Quadling" <rquadl...@googlemail.com>
wrote:
> Can you try dropping the js/ part and put the prototype.js file in the
> same location as the html file?
>
I placed this file in the same loc as prototype.js (V1.6.0_rc0) and it
loads on FF and in IE.
<html>
<head>
<title>Untitled Document</title>
<script type="text/javascript" src="./prototype.js"></script>
<script type="text/javascript">alert(Prototype.Version);</script>
</head>
<body>
</body>
</html>
In both I get an alert with 1.6.0_rc0
Line: 2
Char: 1
Error: Invalid character
Code: 0
URL: file:///C:/ajaxcatalogcd/index_just_prototype.html
This is a signature that tells me, it must be one of the two things:
1. A request for js file is broken, an standard html page with error
is returned, thus signaling an invalid characters so close to the
beginnign of the file.
2. A broken UTF-8 encoding is used (or used but not expected), thus,
same invalid characted error.
1st is more likely. Any virtual Web server (as said already) will help
you out and a http analyzing tool for IE (less - for FF) called
Fiddler. With it you will certainly see what kind of content is
brought back to the page's request for prototype.js. I doubt Fiddler
will work on filesystem protocol (file:///)
Best regards,
Andrew Revinsky
Which appears to be trying to handle the non-implementation of the
addEventListener method on the document object and fix up a
stateChange event on a piece of deferred JavaScript which would then
be hooked to fire the OnContentLoaded meta-event. Weird and groovy
stuff, indeed!
Looks like IE hasn't got the required DOM method and so this gets
invoked and then barfs when the deferred script get loaded from "://
javascript:void(0)". If you take out the leading "://" it doesn't
barf, so I'm guessing that the syntax breaks because of the way IE
handles an implicit file: protocol type (so it works when you load
your original document over http: ).
Presumably it doesn't plop in a default protofol type into the URL for
the src field of this <script> block and IE URL parsing then barfs on
the leading ":" of the src reference.
If you have your own copy of prototype.js, I imagine you could
replace this by a rather less funky mechanism that did the same
thing. Haven't quite got the time to work out how you should do it
though.