createTextNode and IE7
Randy Webb
function insertScript() {
var newScript = document.createElement('script');
newScript.type = "text/javascript";
var s = document.createTextNode("alert('hi');");
newScript.appendChild(s); // problem line
document.getElementById("myDiv").appendChild(newScript);
}
window.onload=insertScript;
I get this error:
Unexpected call to method or property access
And a pointer that points to the newScript.appendChild(s) line.
Am I using createTextNode incorrectly or is IE7 getting it wrong?
The function, as written, works correctly in FF2.0, Opera9 and AIUI,
Safari1.3.2 Its an attempt to get around Safari not supporting the
setting of the .text property of a script element. If IE7 simply won't
create the text and append it then feature testing for createTextNode
won't work. So, I came up with the idea of attempting to set the .text
property with a variable definition then reading that variable. If it is
set, then use the .text property. If it isn't set, then use
createTextNode. Not sure how reliable it is so I thought about using an
IE conditional to isolate IE and go based on that but it reeks of
browser detection.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Martijn Saly
> When running this code in IE7:
>
> function insertScript() {
> var newScript = document.createElement('script');
> newScript.type = "text/javascript";
> var s = document.createTextNode("alert('hi');");
> newScript.appendChild(s); // problem line
> document.getElementById("myDiv").appendChild(newScript);
> }
>
> window.onload=insertScript;
>
> I get this error:
>
> Unexpected call to method or property access
>
> And a pointer that points to the newScript.appendChild(s) line.
>
> Am I using createTextNode incorrectly or is IE7 getting it wrong?
>
> The function, as written, works correctly in FF2.0, Opera9 and AIUI,
> Safari1.3.2 Its an attempt to get around Safari not supporting the
> setting of the .text property of a script element. If IE7 simply won't
> create the text and append it then feature testing for createTextNode
> won't work. So, I came up with the idea of attempting to set the .text
> property with a variable definition then reading that variable. If it is
> set, then use the .text property. If it isn't set, then use
> createTextNode. Not sure how reliable it is so I thought about using an
> IE conditional to isolate IE and go based on that but it reeks of
> browser detection.
>
So basically you're inserting javascript with javascript? :D
Why not put the inserted script directly into your page? Then you won't
have a problem.
--
Martijn Saly
Martin Honnen
> When running this code in IE7:
>
> function insertScript() {
> var newScript = document.createElement('script');
> newScript.type = "text/javascript";
> var s = document.createTextNode("alert('hi');");
> newScript.appendChild(s); // problem line
> document.getElementById("myDiv").appendChild(newScript);
> }
>
> window.onload=insertScript;
>
> I get this error:
>
> Unexpected call to method or property access
>
> And a pointer that points to the newScript.appendChild(s) line.
>
> Am I using createTextNode incorrectly or is IE7 getting it wrong?
This is not related specifically to IE 7, earlier versions of IE don't
do it (the append child on a script element object) either. It is one of
the many problems with IE where the Core DOM stuff applied to a certain
element fails in IE and you need to use the more specialized HTML DOM.
--
Martin Honnen
http://JavaScript.FAQTs.com/
Randy Webb
That is precisely what it is doing.
> Why not put the inserted script directly into your page? Then you won't
> have a problem.
It's purpose is Ajax related. If you retrieve a snippet of HTML using
Ajax and then insert it in a container using innerHTML then any script
blocks in the HTML won't get executed. So you need some way of causing
it to be executed.
Randy Webb
Thank you Martin, it had me scratching my head in wonderment for a
little while. Is there a way to feature detect for that failure without
using try/catch or throwing an error?
How widely feasible is using try/catch now anyway? Is the web and
browsers to the point where try/catch is safe enough to use without
backwards compatibility issues?
ASM
>
> It's purpose is Ajax related. If you retrieve a snippet of HTML using
> Ajax and then insert it in a container using innerHTML then any script
> blocks in the HTML won't get executed. So you need some way of causing
> it to be executed.
I think if you createElement('object') and XHR.responsetext in it
all what is in object fire (even css)
--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Stephane Moriaux and his (less) old Mac already out of date
Randy Webb
> Randy Webb a écrit :
>>
>> It's purpose is Ajax related. If you retrieve a snippet of HTML using
>> Ajax and then insert it in a container using innerHTML then any script
>> blocks in the HTML won't get executed. So you need some way of causing
>> it to be executed.
>
> I think if you createElement('object') and XHR.responsetext in it
> all what is in object fire (even css)
How would you get the responsetext into the container object? Via
innerHTML or how? If you set it via innerHTML then it won't execute
script elements. That's how this whole thing got started was by people
asking "I put my contents in a container but my scripts don't get
executed". There are still flaws with the approach I have so far with
potential scope issues, document.write issues, and code that will go up
the chain using parentNode to get to a container (which goes into the
scope issue).
RobG
> Martin Honnen said the following on 11/30/2006 8:25 AM:
> > This is not related specifically to IE 7, earlier versions of IE don't
> > do it (the append child on a script element object) either. It is one of
> > the many problems with IE where the Core DOM stuff applied to a certain
> > element fails in IE and you need to use the more specialized HTML DOM.
>
> Thank you Martin, it had me scratching my head in wonderment for a
> little while. Is there a way to feature detect for that failure without
> using try/catch or throwing an error?
>
> How widely feasible is using try/catch now anyway? Is the web and
> browsers to the point where try/catch is safe enough to use without
> backwards compatibility issues?
I think your compatibility issues are worse than that - if the loaded
script element assigns something to the innerHTML property of an
element in the page, and you assign to the text property of the script
element before adding it to the page, it will crash IE 6. You can't
even protect users with try..catch:
<script type="text/javascript">
var htmlString = '<hr><script type="text/javascript">'
+ 'var d = document.getElementById(\'testDiv\');'
+ 'd.innerHTML = \'New content\';'
+ '<\/script><br>';
function addHTML(id, htmlString)
{
var target = document.getElementById(id);
target.innerHTML = htmlString;
var el, els = target.getElementsByTagName('script');
var oScript;
for (var i=0, len=els.length; i<len; i++){
el = els[i];
oScript = document.createElement('script');
oScript.type = 'text/javascript';
oScript.text = el.text;
el.parentNode.replaceChild(oScript, el);
}
}
</script>
<div>
<input type="button" value="addHTML"
onclick="addHTML('testDiv', htmlString);">
</div>
Using DOM methods (createTextNode et al) is OK.
How did I discover that? Because I was playing with adding scripts
using both this method and eval'ing the script content (the method used
by Prototype.js) and wanted to resolve a multitude of issues. I think
eval'ing script element content is really awful, so I wanted to see if
this method offers a genuine alternative.
The fix is to add the script element to the page *before* assigning a
value to the text property (a strategy that doesn't help with the
createTextNode problem). The danger is is the severe consequences of
getting the order wrong, and that some future browser may decide to
execute scripts added using innerHTML so the above method will execute
it twice.
I think you have to strip the script element content from the response
text (a RegExp with match does the trick) first, then assign to
innerHTML, then insert replacement script elements and assign to their
text property or use createTextNode as appropriate. Gets tougher, eh?
Incidentally, you also need to deal with external scripts (src="...")
and (if this is to be a widely used library) with people putting HTML
comments in the script elements. That last one hurt, I'd love to say
screw 'em but I'm not sure that is the right attitude.
I'm glad you solved the Safari issue - I'd actually given up on it once
I discovered the above, you've given me new hope. I'd decided that any
script added to a page should come as JSON and be eval'd. There are a
number of other issues associated with that related to scope that your
script/replace method neatly solves.
Regardless of which way you add the script, if it is non-trivial, it
must be specifically designed to be added that way.
Keep at it, maybe you'll finally get there. :-)
--
Rob
Julian Turner
Randy Webb wrote:
[snip]
>It's purpose is Ajax related. If you retrieve a snippet of HTML using
> Ajax and then insert it in a container using innerHTML then any script
> blocks in the HTML won't get executed. So you need some way of causing
> it to be executed.
[/snip]
Hi
I don't know if this is relevant to your problem, but have you explored
adapating any of the ideas discussed on http://dean.edwards.name,
involving the use of hidden IFrames to execute script?
Regards
Julian
Peter Michaux
Randy Webb wrote:
> When running this code in IE7:
>
> function insertScript() {
> var newScript = document.createElement('script');
> newScript.type = "text/javascript";
> var s = document.createTextNode("alert('hi');");
> newScript.appendChild(s); // problem line
> document.getElementById("myDiv").appendChild(newScript);
> }
>
> window.onload=insertScript;
>
> I get this error:
>
> Unexpected call to method or property access
>
> And a pointer that points to the newScript.appendChild(s) line.
>
> Am I using createTextNode incorrectly or is IE7 getting it wrong?
>
> The function, as written, works correctly in FF2.0, Opera9 and AIUI,
What is "AIUI"?
> Safari1.3.2 Its an attempt to get around Safari not supporting the
> setting of the .text property of a script element. If IE7 simply won't
> create the text and append it then feature testing for createTextNode
> won't work. So, I came up with the idea of attempting to set the .text
> property with a variable definition then reading that variable.
I was doing this weeks ago :) You even saw a page of mine that did
exactly this. Remember that "insert code" thing I had for code
examples. Below is the code I used to determine if the page is capable
of inserting scripts with your technique plus the necessary option for
Safari. I try the IE method first because as far as i remember it
doesn't error in Safari but trying them in the other order does error
in IE. However I did put the tests in try-catch blocks for good (or
bad) measure.
function newInserter() {
var hooks = [
function(script, code) { // IE
script.text = code;
},
function(script, code) { // Safari
code = document.createTextNode(code);
script.appendChild(code);
}
];
var hook = null;
function insertExampleCode(code) {
var script = document.createElement('script');
script.type = 'text/javascript';
hook(script, code);
document.body.appendChild(script);
}
var testCode = "var testInsertion={b:3};"
for (var i=0; i<hooks.length; i++) {
hook = hooks[i];
try {
insertExampleCode(testCode);
if (testInsertion && testInsertion.b === 3) {
return insertExampleCode;
}
} catch (e) {}
}
return null;
}
> If it is
> set, then use the .text property. If it isn't set, then use
> createTextNode.
Just because text property doesn't work, it doesn't mean that
createTextNode will work. It is just as easy to test both as test one.
> Not sure how reliable it is so I thought about using an
> IE conditional to isolate IE and go based on that but it reeks of
> browser detection.
I just retested the above coded with success in Mac/Safari 2, Mac/Opera
9, Mac/Firefox 1.5, Win/IE 5.5, Win/IE 6, Win/Netscape 6.
Win/IE 5.01 gives and "unexpected quantifier" error.
Win/IE 4 gives a "syntax error" and then "object expected"
----------------
Clearly there is appeal to your technique which is why I played with it
until I found the Safari problem. Then I started to get nervous that
some other browser might be able to do XHR but the script blocks
wouldn't run.
The advantage of using eval() is that as long as the programmer knows
how the code has to be written then it is extremely likely that the
browser will be able to run the scripts. Success is the most important
part. If the script blocks are written with care then they could also
run if your technique is proven to work and the use of eval is changed
to your technique.
Peter
Peter Michaux
Peter Michaux wrote:
>
> Randy Webb wrote:
>
> > Not sure how reliable it is so I thought about using an
> > IE conditional to isolate IE and go based on that but it reeks of
> > browser detection.
>
> I just retested the above coded with success in Mac/Safari 2, Mac/Opera
> 9, Mac/Firefox 1.5, Win/IE 5.5, Win/IE 6, Win/Netscape 6.
>
> Win/IE 5.01 gives and "unexpected quantifier" error.
>
> Win/IE 4 gives a "syntax error" and then "object expected"
I just realized there was other code being run as well. I don't know
which code was giving the errors.
Peter
RobG
Peter Michaux wrote:
> Randy Webb wrote:
> > The function, as written, works correctly in FF2.0, Opera9 and AIUI,
>
> What is "AIUI"?
"As I understand it". :-)
[...]
> Clearly there is appeal to your technique which is why I played with it
> until I found the Safari problem. Then I started to get nervous that
> some other browser might be able to do XHR but the script blocks
> wouldn't run.
>
> The advantage of using eval() is that as long as the programmer knows
> how the code has to be written then it is extremely likely that the
> browser will be able to run the scripts.
The simplicity of the eval method is alluring, however the whole
exercise is based on using innerHTML which isn't part of a standard
anyway. JSON already freely uses eval so there is some acceptance of
its use there.
Perhaps there is something in the DOM 3 (XML) Load and Save spec?
--
Rob
Peter Michaux
> Peter Michaux wrote:
> > Randy Webb wrote:
> [...]
> > > The function, as written, works correctly in FF2.0, Opera9 and AIUI,
> >
> > What is "AIUI"?
>
> "As I understand it". :-)
For a minute there I was worried it was some new browser I had not
heard about from Microsoft and they were going to cram it down 90% of
the market's throat and that it's userAgent string was "ice weasel", it
had window.opera, used only netscape's layers and didn't have
innerHTML.
Peter
Randy Webb
And maybe IE will support it in IE27?
Randy Webb
If you use an IFrame to execute your scripts that defeats the purpose of
using the XMLHttpRequest object as you could just load the page in the
IFrame, the script gets executed, grab the results and dump it in the
main page. (That is how 'ajax' was done before XMLHttpRequest came about).
And, the IFrame tricks discussed are about getting eval'ed code out of
the current scope into a scope of it's own and I am trying to get code
back into it's proper scope.
Randy Webb
> Hi Randy,
>
> Randy Webb wrote:
>> When running this code in IE7:
>>
>> function insertScript() {
>> var newScript = document.createElement('script');
>> newScript.type = "text/javascript";
>> var s = document.createTextNode("alert('hi');");
>> newScript.appendChild(s); // problem line
>> document.getElementById("myDiv").appendChild(newScript);
>> }
>>
>> window.onload=insertScript;
>>
>> I get this error:
>>
>> Unexpected call to method or property access
>>
>> And a pointer that points to the newScript.appendChild(s) line.
>>
>> Am I using createTextNode incorrectly or is IE7 getting it wrong?
>>
>> The function, as written, works correctly in FF2.0, Opera9 and AIUI,
>
> What is "AIUI"?
No, it doesn't support window.opera but it has all the rest of your
nightmares :)
>> Safari1.3.2 Its an attempt to get around Safari not supporting the
>> setting of the .text property of a script element. If IE7 simply won't
>> create the text and append it then feature testing for createTextNode
>> won't work. So, I came up with the idea of attempting to set the .text
>> property with a variable definition then reading that variable.
>
> I was doing this weeks ago :) You even saw a page of mine that did
> exactly this. Remember that "insert code" thing I had for code
> examples.
Yes, this thread:
Was the one I remembered seeing that had the code I used in it and where
I got the idea from that caused this thread to be created.
Looks like a convoluted way of doing this:
function insertScript(scriptContents) {
var useIt = false;
var testScript = document.createElement('script');
testScript.type = "text/javascript";
testScript.text = "var useText=true";
document.getElementById("myDiv").appendChild(testScript);
var newScript = document.createElement('script');
newScript.type = "text/javascript";
if(useText)
{
newScript.text = scriptContents;
}
else
{
//Opera 9 falls through to this branch.
var s = document.createTextNode(scriptContents);
newScript.appendChild(s);
}
document.getElementById("myDiv").appendChild(newScript);
}
Although the only browser I know of that won't use createTextNode is IE.
What does that code do in Safari (in fact, any mac browser) when called
with a insertScript('alert("It worked")') ?
>> If it is
>> set, then use the .text property. If it isn't set, then use
>> createTextNode.
>
> Just because text property doesn't work, it doesn't mean that
> createTextNode will work. It is just as easy to test both as test one.
It's possible, but unless I see one, or hear of one, I will leave it as
simple as possible which is the goal.
>> Not sure how reliable it is so I thought about using an
>> IE conditional to isolate IE and go based on that but it reeks of
>> browser detection.
>
> I just retested the above coded with success in Mac/Safari 2, Mac/Opera
> 9, Mac/Firefox 1.5, Win/IE 5.5, Win/IE 6, Win/Netscape 6.
What do the Mac browsers (and even NS6 Win) do with the code above I posted?
> Clearly there is appeal to your technique which is why I played with it
> until I found the Safari problem. Then I started to get nervous that
> some other browser might be able to do XHR but the script blocks
> wouldn't run.
I don't use XHR so this is mostly an academic exercise for me as I use
.js files and dynamically load them on the fly.
> The advantage of using eval() is that as long as the programmer knows
> how the code has to be written then it is extremely likely that the
> browser will be able to run the scripts.
Most JS programmers don't understand how to control eval and when to/not
to use it though. The major drawback to eval here is the scope chain. I
haven't decided on an attempted course to try to deal with the scope
issue yet but I have some ideas.
> Success is the most important part.
Without a doubt.
> If the script blocks are written with care then they could also
> run if your technique is proven to work and the use of eval is changed
> to your technique.
I don't know that I can make mine work but I won't stop trying to :) I
have been modifying the loadJSFile function for about 5 years now :)
Peter Michaux
Each time you insert a script you are making the same test. If the page
will only insert once then that is fine. However with multiple uses you
are making the same test unnecessarily. Of course you already know this
and it is personal preference. I like Richard's style of testing once
and then setting a very short efficient function to be used repeatedly.
> Although the only browser I know of that won't use createTextNode is IE.
>
> What does that code do in Safari (in fact, any mac browser) when called
> with a insertScript('alert("It worked")') ?
<snip>
> What do the Mac browsers (and even NS6 Win) do with the code above I posted?
If you post some examples at a few different URLs then I can click them
in Safari 2.0.4 and if the issue is still interesting in a few weeks I
can also click them in Safari 1.3.9.
> > The advantage of using eval() is that as long as the programmer knows
> > how the code has to be written then it is extremely likely that the
> > browser will be able to run the scripts.
>
> Most JS programmers don't understand how to control eval and when to/not
> to use it though.
Unless the alternative is better and has less drawbacks, I really am ok
with letting other programmers shoot themselves in the foot as long as
the capability to do it right is in the compromise solution.
> I don't know that I can make mine work but I won't stop trying to :) I
> have been modifying the loadJSFile function for about 5 years now :)
Using eval with care will work today (and I'm all stressed about
setting opacity well). Not that your attempts should be discouraged.
I'd rather do it your way.
Peter
Julian Turner
Randy Webb wrote:
[snip]
> And, the IFrame tricks discussed are about getting eval'ed code out of
> the current scope into a scope of it's own and I am trying to get code
> back into it's proper scope.
[/snip]
Hi
I appreciate the point your are making here, and that the IFrame trick
is not relevant.
I am not sure I fully understand the issues you have with eval and
proper scope, and therefore why inserting script with a script tag is
preferrable to eval'ing it.
I think I understand that if I eval script, then it will get its own
scope based on the scope of the function in which it it is eval'd.
Is the problem this: your script is trying to introduce variables and
declared functions to be available in the scope chains of
**previously** imported script? Or am I way off the mark?
Regards
Julian Turner
Randy Webb
> Randy Webb wrote:
>
> [snip]
>> And, the IFrame tricks discussed are about getting eval'ed code out of
>> the current scope into a scope of it's own and I am trying to get code
>> back into it's proper scope.
> [/snip]
>
> Hi
>
> I appreciate the point your are making here, and that the IFrame trick
> is not relevant.
It may end up not being irrelevant, I honestly don't know yet. I do
think it doesn't solve the issue I am pondering on though :) And, to be
totally honest, I don't have the issue in any site I am working on. It's
more of a mental exercise than anything else.
> I am not sure I fully understand the issues you have with eval and
> proper scope, and therefore why inserting script with a script tag is
> preferrable to eval'ing it.
Simple scenario. Let's say a page is loaded via XHR. That document has a
script block in it with this code snippet:
<script>
var myVar = "My name is Randy";
</script>
Just any global variable.
You load the HTML, insert it in a container, then want to execute the
script block. You run a function that evals the script contents. myVar
then becomes local to the function.
The biggest thing? I hate eval :)
Second scenario is one that I can not come up with a reasonable reason
to ever do but it involves a script block that traverses the tree going
upwards using parentNode to get to an element. As I say, that is a
perverse scenario that if I ever saw actual code that did it I would
probably wonder what insane asylum the author was a patient at.
> I think I understand that if I eval script, then it will get its own
> scope based on the scope of the function in which it it is eval'd.
Yes it does.
function function1(theArg){
eval(theArg)
}
function function2(){
alert(myVar)
}
function1('var myVar = "My name is Randy"')
If the argument to that function1 call is the string being loaded via
XHR and passed to function1 to be executed, then in it's original form
it would be a global variable. After being eval'ed it becomes local.
Using createTextNode or the .text property it retains it's global scope.
> Is the problem this: your script is trying to introduce variables and
> declared functions to be available in the scope chains of
> **previously** imported script? Or am I way off the mark?
Close. Three years ago you didn't see questions in this group with
regards to XMLHttpRequest and/or AJAX very often. Now, you see a
kazillion of them. The next phase of that, to me, is going to be script
issues and it is already happening where people are asking "How do I
make my scripts execute when loaded with AJAX" and I am simply trying to
be ahead of it and come up with an answer before the onslaught happens.
Personally, I don't use AJAX to load data. What dictates how you load
data is how your back end is set up. People seem to think that you can
simply take a huge site and convert it to AJAX and everything keeps
going when that isn't true. If you have a site that has, say, 100 pages
to it. OK, lets make it an AJAX site. Create a new first page, use AJAX
to load the other pages and drop them in a div container. Simple, and
you now have an "AJAX site". That is what it seems a lot of people are
doing and it runs into the "My scripts don't execute" scenario. Where if
the site is setup and maintained to be an AJAX driven site then the
"pages" aren't complete HTML pages and don't stand on there own.
The approach I use, and prefer, for loading data is .js files and
loading them on the fly. The back end still has to be set up to create
those .js files and the main page is set up to handle it. I just find
the .js files simpler and more reliable than AJAX is all.
Peter Michaux
> Simple scenario. Let's say a page is loaded via XHR.
Maybe this is just semantics but folks don't usually load a page with
XHR but rather an HTML snip that may contain script blocks.
> The biggest thing? I hate eval :)
but Randy, eval is the only way to write dynamic code like this...
eval("myObj." + foo + "=" + bar);
:-) Ok. Seriously...
I haven't run tests, but as far as I know, eval is the quickest way to
parse trusted json. The alternative is a relatively lengthy json parser
written in JavaScript.
> Three years ago you didn't see questions in this group with
> regards to XMLHttpRequest and/or AJAX very often. Now, you see a
> kazillion of them. The next phase of that, to me, is going to be script
> issues and it is already happening where people are asking "How do I
> make my scripts execute when loaded with AJAX" and I am simply trying to
> be ahead of it and come up with an answer before the onslaught happens.
This attitude plus FAQ mantainer: a true humanitarian!
> Personally, I don't use AJAX to load data. What dictates how you load
> data is how your back end is set up. People seem to think that you can
> simply take a huge site and convert it to AJAX and everything keeps
> going when that isn't true. If you have a site that has, say, 100 pages
> to it. OK, lets make it an AJAX site. Create a new first page, use AJAX
> to load the other pages and drop them in a div container. Simple, and
> you now have an "AJAX site". That is what it seems a lot of people are
> doing and it runs into the "My scripts don't execute" scenario. Where if
> the site is setup and maintained to be an AJAX driven site then the
> "pages" aren't complete HTML pages and don't stand on there own.
>
> The approach I use, and prefer, for loading data is .js files and
> loading them on the fly. The back end still has to be set up to create
> those .js files and the main page is set up to handle it. I just find
> the .js files simpler and more reliable than AJAX is all.
But once a site starts submitting forms with Ajax then the whole site
may as well switch over to Ajax all together, don't you think?
Peter
Julian Turner
Randy Webb wrote:
[snip]
> You load the HTML, insert it in a container, then want to execute the
> script block. You run a function that evals the script contents. myVar
> then becomes local to the function.
[/snip]
I see the point.
I suppose the question then is in what circumstances is myVar being
local a problem that does not have a work-around?
> The biggest thing? I hate eval :)
It's reputation is definitely not helped when it is misused.
For a particularly egregious example of misuse, and for fun only, I use
eval for my own libraries to nest my modules (with a downward only
dependency)
E.g.
module1 - core functions
module2 - Array, String - uses module1
module3 - HTML - uses modules 2 and 2
function module1()
{
this.closure = function(source)
{
var retVal;
eval(source);
return retVal;
};
function module1Function() {
alert("hello from module1");
}
this.module1Function = module1Function;
}
function module2()
{
this.closure = function(source)
{
var retVal;
eval(source);
return retVal;
};
function module2Function() {
module1Function(); // Will be in scope chain
}
this.module2Function = module2Function;
}
function module3()
{
function module3Function() {
module2Function(); // Will be in scope chain
}
this.module3Function = module3Function
}
module1 = new module1();
module2 = module1.closure(module2.toString() + " retVal = new
module2()");
module3 = module2.closure(module3.toString() + "retVal = new
module3()");
module3.module3Function();
The real version is a little more friendly, but that hopefully
illustrates the insane gist of it.
I know, I know, closures, scopes and scope chain look-ups lead to poor
memory and speed performance, but in practice I am not noticing much of
a performance hit for modest applications.
> Second scenario is one that I can not come up with a reasonable reason
> to ever do but it involves a script block that traverses the tree going
> upwards using parentNode to get to an element. As I say, that is a
> perverse scenario that if I ever saw actual code that did it I would
> probably wonder what insane asylum the author was a patient at.
I am not sure I follow this.
[snip]
> Close. Three years ago you didn't see questions in this group with
> regards to XMLHttpRequest and/or AJAX very often. Now, you see a
> kazillion of them. The next phase of that, to me, is going to be script
> issues and it is already happening where people are asking "How do I
> make my scripts execute when loaded with AJAX" and I am simply trying to
> be ahead of it and come up with an answer before the onslaught happens.
[/snip]
Anticipation is good.
[snip]
> The approach I use, and prefer, for loading data is .js files and
> loading them on the fly. The back end still has to be set up to create
> those .js files and the main page is set up to handle it. I just find
> the .js files simpler and more reliable than AJAX is all.
[/snip]
It is also patented!
Regards
Julian
Randy Webb
> Randy Webb wrote:
<snip>
>> The approach I use, and prefer, for loading data is .js files and
>> loading them on the fly. The back end still has to be set up to create
>> those .js files and the main page is set up to handle it. I just find
>> the .js files simpler and more reliable than AJAX is all.
> [/snip]
>
> It is also patented!
>
> <URL:http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6,941,562.PN.&OS=PN/6,941,562&RS=PN/6,941,562>
How does one challenge a US Patent then? I beat them to that by about 4
years or so. And, I can prove it.
March 9, 2003 is the date on the files in this FTP listing:
<URL: ftp://members.aol.com/justhikk/>
And that is precisely why I haven't updated that page is to date when I
first started using dynamic loading script files. And that is not when I
first started using it, it is when that page got last updated (after I
had it working). The only problem with that page is about half the .js
files didn't get created/uploaded.
So, how do I get my patent they stole from me?
Julian Turner
Randy Webb wrote:
> How does one challenge a US Patent then? I beat them to that by about 4
> years or so. And, I can prove it.
>
> March 9, 2003 is the date on the files in this FTP listing:
>
> <URL: ftp://members.aol.com/justhikk/>
>
> And that is precisely why I haven't updated that page is to date when I
> first started using dynamic loading script files. And that is not when I
> first started using it, it is when that page got last updated (after I
> had it working). The only problem with that page is about half the .js
> files didn't get created/uploaded.
>
> So, how do I get my patent they stole from me?
I just mentioned it for a laugh :)
I don't know much about the US patent system, but I get the strong
impression (and I am happy to be corrected) that the US patent office
does not really do much of a prior-art search, and accepts almost
anything it is given, so that a number of speculative applications make
it onto the books and then get challenged later (if you have the money)
or ignored. If I am right, I can't say I agree with that system,
particularly when it comes to software, as patents and software do not
sit easily together.
The open source movement is partly in existence as a counter-balance to
this problem, I think.
Certainly in the UK (my jurisdiction), the patent office takes a lot
more persuading to grant a patent, software is very hard to patent
(although Microsoft and other large concerns are always trying to lobby
for more), and a patent can always be challenged by "prior art" or
"obviousness" later on.
Regards
Julian
VK
>
> How does one challenge a US Patent then? I beat them to that by about 4
> years or so. And, I can prove it.
>
> March 9, 2003 is the date on the files in this FTP listing:
>
> <URL: ftp://members.aol.com/justhikk/>
Alas, 2003 is not old enough, so you may safely remove these files.
Their priority is protected by the U.S. Provisional Application No.
60/251,056 filed Dec. 1, 2000
This way you need a something older than 12.01.2000
I also noticed an important patent status change since the last time I
checked it: it is not "pending request" anymore, it's "patented case"
now:
Eolas-2 is coming?
Peter Michaux
>
> > Although the only browser I know of that won't use createTextNode is IE.
> >
> > What does that code do in Safari (in fact, any mac browser) when called
> > with a insertScript('alert("It worked")') ?
> <snip>
> > What do the Mac browsers (and even NS6 Win) do with the code above I posted?
>
> If you post some examples at a few different URLs then I can click them
> in Safari 2.0.4 and if the issue is still interesting in a few weeks I
> can also click them in Safari 1.3.9.
I've done most of the work to check out script insertion with
mainstream browsers and some exotics. See the tests and results
http://peter.michaux.ca/temp/insertScripts.html
The bad news is neither script insertion method works with NN6. The
iCab failure is a worry because that is a current release. Even if iCab
isn't mainstream some equally lesser known browsers on portable devices
could have failure too. I don't know about Safari <2 yet. Later today.
It would seem bad to depend on an technique for use with XHR when NN6
isn't really ancient yet has XHR. The fact some rare XHR browsers can't
use this technique makes me nervous that depending on the technique
could cause a major backfire in the future.
The eval() technique works. It is part of the language so part of an
old standard. I think using eval is the conservative choice.
Peter
Randy Webb
> Peter Michaux wrote:
>>> Although the only browser I know of that won't use createTextNode is IE.
>>>
>>> What does that code do in Safari (in fact, any mac browser) when called
>>> with a insertScript('alert("It worked")') ?
>> <snip>
>>> What do the Mac browsers (and even NS6 Win) do with the code above I posted?
>> If you post some examples at a few different URLs then I can click them
>> in Safari 2.0.4 and if the issue is still interesting in a few weeks I
>> can also click them in Safari 1.3.9.
>
> I've done most of the work to check out script insertion with
> mainstream browsers and some exotics.
Can I impose on you to ask to test this page with the browsers not
listed there?
<URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/index.html>
I edited it and added the browsers/OS that you have listed that aren't
on that page. They should show up with a blue background and "Untested"
in the boxes.
> See the tests and results
>
> http://peter.michaux.ca/temp/insertScripts.html
Firefox 2.0 WinXP - success on both.
Opera 9.0 WinXP - success on both.
Mozila 1.7.8 - success on both.
You can duplicate the results for IE6/XP for IE7/XP
> The bad news is neither script insertion method works with NN6.
NN6 shouldn't be a concern as it is old enough that it isn't worth
worrying with. Netscape is up to 8.0 and NS users tend to parallel
Opera/Mozilla/Firefox users where they tend to keep it updated.
> The iCab failure is a worry because that is a current release. Even if iCab
> isn't mainstream some equally lesser known browsers on portable devices
> could have failure too. I don't know about Safari <2 yet. Later today.
iCab doesn't like my dynamic loading either. Does it support XHR though?
> It would seem bad to depend on an technique for use with XHR when NN6
> isn't really ancient yet has XHR. The fact some rare XHR browsers can't
> use this technique makes me nervous that depending on the technique
> could cause a major backfire in the future.
No more so than depending on XHR to start with. If you are worried about
failure with executing the scripts because of an old browser then you
need to worry about using XHR before then.
> The eval() technique works. It is part of the language so part of an
> old standard. I think using eval is the conservative choice.
Then why not just make all your code strings and eval it? Seriously,
eval has its problems and it may solve some problems but it introduces
problems of its own as well.
Peter Michaux
>
> Can I impose on you to ask to test this page with the browsers not
> listed there?
>
> <URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/index.html>
>
> I edited it and added the browsers/OS that you have listed that aren't
> on that page. They should show up with a blue background and "Untested"
> in the boxes.
Ok. I clicked each of the buttons and refreshed between each click. If
I saw an alert I called it a success.
Results are appended at the bottom of this email for the browsers I
have. I checked Konq by chatting on irc #kde so couldn't check now.
BTW, where did you get OS X 10.6.2 ?!?!?!
> > The bad news is neither script insertion method works with NN6.
>
> NN6 shouldn't be a concern as it is old enough that it isn't worth
> worrying with. Netscape is up to 8.0 and NS users tend to parallel
> Opera/Mozilla/Firefox users where they tend to keep it updated.
>
> > The iCab failure is a worry because that is a current release. Even if iCab
> > isn't mainstream some equally lesser known browsers on portable devices
> > could have failure too. I don't know about Safari <2 yet. Later today.
>
> iCab doesn't like my dynamic loading either. Does it support XHR though?
Yes iCab 3.0.3 does support XHR
I don't know what your tests are doing compared to mine but my simple
script insertions failed in iCab. Two of your tests worked.
> > It would seem bad to depend on an technique for use with XHR when NN6
> > isn't really ancient yet has XHR. The fact some rare XHR browsers can't
> > use this technique makes me nervous that depending on the technique
> > could cause a major backfire in the future.
>
> No more so than depending on XHR to start with.
Yes more than depending on XHR. Actually that was my point. If NN6 has
XHR but can't insert scripts then the insert scripts is an added
limitation on the number of supported browsers. Again, I don't know
what is going on with your iCab tests but it is almost certain there
will be browsers that can't insert scripts but do have eval, don't you
think?
Really NN6 isn't my biggest concern. It is newer browsers in mobil
devices.
> If you are worried about
> failure with executing the scripts because of an old browser then you
> need to worry about using XHR before then.
Agreed
> > The eval() technique works. It is part of the language so part of an
> > old standard. I think using eval is the conservative choice.
>
> Then why not just make all your code strings and eval it? Seriously,
> eval has its problems and it may solve some problems but it introduces
> problems of its own as well.
But I'm scared :S Scared of deploying a novel non-standard technique
that makes programming easier but that might break when another
standard technique that rarely involves any tricky programming is
almost guarrenteed success. Imagine having to explain that to the boss.
Two particular eff words might follow.
Peter
// ------------------------------------------------------------------
<tr>
<td class="PC" width="160px">Netscape 8.0.4</td>
<td class="PC" width="110px">Win XP</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="PC" width="160px">Netscape 7.0</td>
<td class="PC" width="110px">Win XP</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="PC" width="160px">Netscape 6.0</td>
<td class="PC" width="110px">Win XP</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="no">No</td>
</tr>
<tr>
<td class="MAC">Camino 1.0.3</td>
<td class="MAC">MacOS 10.4.8</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td></td>
</tr>
<tr>
<td class="MAC">Opera 9.02</td>
<td class="MAC">MacOS 10.4.8</td>
<td class="yes">Yes</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td></td>
</tr>
<tr>
<td class="MAC">Shiira 1.2.2</td>
<td class="MAC">MacOS 10.4.8</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td></td>
</tr>
<tr>
<td class="MAC">Sunrise 0.89</td>
<td class="MAC">MacOS 10.4.8</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td></td>
</tr>
<tr>
<td class="MAC">Firefox 2.0 </td>
<td class="MAC">MacOS 10.4.8</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td></td>
</tr>
<tr>
<td class="MAC">Firefox 1.5.0.8</td>
<td class="MAC">MacOS 10.4.8</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td></td>
</tr>
<tr>
<td class="MAC">iCab 3.0.3 </td>
<td class="MAC">MacOS 10.4.8</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td></td>
</tr>
Peter Michaux
> Randy Webb wrote:
> I don't know what your tests are doing compared to mine but my simple
> script insertions failed in iCab. Two of your tests worked.
I just read your source. I see that you are testing loading js files on
the fly vs. I was testing script insertion: apples and oranges.
Peter
Randy Webb
> Randy Webb wrote:
>> Can I impose on you to ask to test this page with the browsers not
>> listed there?
>>
>> <URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/index.html>
>>
>> I edited it and added the browsers/OS that you have listed that aren't
>> on that page. They should show up with a blue background and "Untested"
>> in the boxes.
>
> Ok. I clicked each of the buttons and refreshed between each click. If
> I saw an alert I called it a success.
>
> Results are appended at the bottom of this email for the browsers I
> have. I checked Konq by chatting on irc #kde so couldn't check now.
>
> BTW, where did you get OS X 10.6.2 ?!?!?!
I was being pshycic :) Thank you for pointing out my typo error in a
copy paste. Not sure how I managed that.
>>> The bad news is neither script insertion method works with NN6.
>> NN6 shouldn't be a concern as it is old enough that it isn't worth
>> worrying with. Netscape is up to 8.0 and NS users tend to parallel
>> Opera/Mozilla/Firefox users where they tend to keep it updated.
>>
>>> The iCab failure is a worry because that is a current release. Even if iCab
>>> isn't mainstream some equally lesser known browsers on portable devices
>>> could have failure too. I don't know about Safari <2 yet. Later today.
>> iCab doesn't like my dynamic loading either. Does it support XHR though?
>
> Yes iCab 3.0.3 does support XHR
>
> I don't know what your tests are doing compared to mine but my simple
> script insertions failed in iCab. Two of your tests worked.
createElement test - uses createElement to create a script block and set
its .src property to load a .js file
change innerHTML - changes the innerHTML of a div tag to load a .js file
change source - changes the .src property of an existing script block
>
>>> It would seem bad to depend on an technique for use with XHR when NN6
>>> isn't really ancient yet has XHR. The fact some rare XHR browsers can't
>>> use this technique makes me nervous that depending on the technique
>>> could cause a major backfire in the future.
>> No more so than depending on XHR to start with.
>
> Yes more than depending on XHR. Actually that was my point. If NN6 has
> XHR but can't insert scripts then the insert scripts is an added
> limitation on the number of supported browsers.
If the string from an XHR requests has a script block in it, and you
insert it via innerHTML, then the script block gets loaded and executed
in early Netscape 6. Not sure what version of NS6 that changed in though.
> Again, I don't know what is going on with your iCab tests but it is
> almost certain there will be browsers that can't insert scripts but
> do have eval, don't you think?
I don't think there is, I am pretty positive there are some around. But
the same goes for XHR where there will be browsers that support loading
scripts but don't support XHR. Its a tradeoff.
> Really NN6 isn't my biggest concern. It is newer browsers in mobil
> devices.
How many mobile devices support XHR though?
>>> The eval() technique works. It is part of the language so part of an
>>> old standard. I think using eval is the conservative choice.
>> Then why not just make all your code strings and eval it? Seriously,
>> eval has its problems and it may solve some problems but it introduces
>> problems of its own as well.
>
> But I'm scared :S Scared of deploying a novel non-standard technique
> that makes programming easier but that might break when another
> standard technique that rarely involves any tricky programming is
> almost guarrenteed success. Imagine having to explain that to the boss.
> Two particular eff words might follow.
My point was that just because something works doesn't mean you should
do it that way. In the end eval may be the most reliable way to go but
until then, I am still working on this approach to go with my loadJSFile
function :)
<snip>
Randy Webb
Yes, I am loading files on the fly. I am probably going to add something
along the lines of your test page results to it where it also indicates
support (or lack of) for changing the .text property of a script element
and the support for createTextNode
Peter Michaux
>
> Yes, I am loading files on the fly. I am probably going to add something
> along the lines of your test page results to it where it also indicates
> support (or lack of) for changing the .text property of a script element
> and the support for createTextNode
Let me know when and I'll do more clicking. I'm interested in these
results as a whole.
Peter
Randy Webb
The preliminary file is here:
<URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/index2.html>
The results are mostly what you had already. I have to change the
functions to report errors and error out better. Right now, it simply
throws the default browser error. Probably change it to a function
similar to yours instead of throwing up error boxes. Also have to tinker
with the CSS some more (it scrolls off the screen in IE).
RobG
Randy Webb wrote:
> Peter Michaux said the following on 12/7/2006 12:51 PM:
> > Randy Webb wrote:
> >> Yes, I am loading files on the fly. I am probably going to add something
> >> along the lines of your test page results to it where it also indicates
> >> support (or lack of) for changing the .text property of a script element
> >> and the support for createTextNode
> >
> > Let me know when and I'll do more clicking. I'm interested in these
> > results as a whole.
>
> The preliminary file is here:
>
> <URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/index2.html>
If I click on the "Create Element" button, I get the following error:
ocument is not defined -- index.html line 18
ocument.getElementById('scriptDiv').appendChild(s);
--^
--
Rob
Randy Webb
I know :( I found that error after uploading it. I have a new one to
uploaded that has some updated information on the .text property and
createTextNode methods. It has also been moved/renamed to index.html
instead of index2.html:
<URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/>
index2.html has been deleted.
Peter Michaux
> RobG said the following on 12/13/2006 11:45 PM:
> > Randy Webb wrote:
> >> Peter Michaux said the following on 12/7/2006 12:51 PM:
> >>> Randy Webb wrote:
> >>>> Yes, I am loading files on the fly. I am probably going to add something
> >>>> along the lines of your test page results to it where it also indicates
> >>>> support (or lack of) for changing the .text property of a script element
> >>>> and the support for createTextNode
> >>> Let me know when and I'll do more clicking. I'm interested in these
> >>> results as a whole.
> >> The preliminary file is here:
> >>
> >> <URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/index2.html>
> >
> > If I click on the "Create Element" button, I get the following error:
> >
> > ocument is not defined -- index.html line 18
> >
> > ocument.getElementById('scriptDiv').appendChild(s);
> > --^
>
> I know :( I found that error after uploading it. I have a new one to
> uploaded that has some updated information on the .text property and
> createTextNode methods. It has also been moved/renamed to index.html
> instead of index2.html:
>
> <URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/>
I noticed a few things
In one row you have OS X 10.4 but all others are 10.4.8
You really have IE 5.2 on OS X 10.4? I just wonder because it came
standard on 10.3 and you have Safari 1.3 on 10.3.
What's going on with the contradictory iCab 3.0.3 results?
If iCab is the only current release browser that is red from left to
right do you just say "screw, iCab"?
Peter
Randy Webb
> Randy Webb wrote:
>> RobG said the following on 12/13/2006 11:45 PM:
>>> Randy Webb wrote:
>>>> Peter Michaux said the following on 12/7/2006 12:51 PM:
>>>>> Randy Webb wrote:
>>>>>> Yes, I am loading files on the fly. I am probably going to add something
>>>>>> along the lines of your test page results to it where it also indicates
>>>>>> support (or lack of) for changing the .text property of a script element
>>>>>> and the support for createTextNode
>>>>> Let me know when and I'll do more clicking. I'm interested in these
>>>>> results as a whole.
>>>> The preliminary file is here:
>>>>
>>>> <URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/index2.html>
>>> If I click on the "Create Element" button, I get the following error:
>>>
>>> ocument is not defined -- index.html line 18
>>>
>>> ocument.getElementById('scriptDiv').appendChild(s);
>>> --^
>> I know :( I found that error after uploading it. I have a new one to
>> uploaded that has some updated information on the .text property and
>> createTextNode methods. It has also been moved/renamed to index.html
>> instead of index2.html:
>>
>> <URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/>
>
> I noticed a few things
>
> In one row you have OS X 10.4 but all others are 10.4.8
All of the mac data comes from other people. I honestly don't remember
who gave me the 10.4 data (I should start noting it I guess) but if you
can confirm the data as being accurate in 10.4.8 then it can be changed
to be uniform. The 10.4.8 came from your page, the 10.4 probably came
from either Richard Cornford or ASM.
> You really have IE 5.2 on OS X 10.4? I just wonder because it came
> standard on 10.3 and you have Safari 1.3 on 10.3.
<shrug> Another of those me depending on others for the mac results. I
will try to find where I got that data from (Its in the archives
somewhere). For now it is changed to 10.3 until I can confirm it. I am
probably going to rearrange the mac section by OS version number so that
all the 10.3's are together, 10.4, etc.. Probably do the WinME/XP
section the same way.
> What's going on with the contradictory iCab 3.0.3 results?
More than likely, a copy/paste error on my part.
> If iCab is the only current release browser that is red from left to
> right do you just say "screw, iCab"?
Pretty much :) iCab doesn't seem to be a very dynamic scriptable browser.
I corrected the iCab 3.0.3 results locally and will upload it tonight.
Peter Michaux
Randy Webb wrote:
>
> <URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/>
Is this file really working? Now I'm getting all failures on the first
test in the XP browsers I tried. It is strange though because on the
first two clicks I see no activity, on the third click i see
"Downloading blah blah blah" in the status bar but when it finishes
downloading I don't see the alert. I think the other tests are working
but maybe you can look again before I click about 100 times in 20
browsers.
Off topic but what is the difference with putting urls in <URL: > vs.
just in <> like VK suggested?
Peter
Richard Cornford
<snip>
> like VK suggested?
Haven't you read enough of his posts yet to be beyond being interested
in anything VK 'suggests'?
Richard.
John W. Kennedy
The <URL: > convention was once an official part of the URL standard, as
the one and only correct way to embed a URL in plain text. It was
removed from the standard for lack of use, but a good deal of software
still supports it.
The < > convention was never official, but some software supports it all
the same.
I have personally had better results with the <URL: > convention.
--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
Peter Michaux
> Peter Michaux wrote:
> > Off topic but what is the difference with putting urls in <URL: > vs.
> > just in <> like VK suggested?
>
> The <URL: > convention was once an official part of the URL standard, as
> the one and only correct way to embed a URL in plain text. It was
> removed from the standard for lack of use, but a good deal of software
> still supports it.
>
> The < > convention was never official, but some software supports it all
> the same.
>
> I have personally had better results with the <URL: > convention.
Thanks.
Peter
Randy Webb
> Hi Randy,
>
> Randy Webb wrote:
>> <URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/>
>
> Is this file really working?
I can verify that my local copy works. As for the online copy, I can't
even get the nice wonderful AOL server to even serve me the file to test
it :\
After testing it with the full filename it seems to be loading it for me
now in Opera 9.0 and all of the buttons work as designed.
I emailed you all the files it uses. If it fails to send the files for
some reason, let me know and I will post a .zip file somewhere.
> Now I'm getting all failures on the first test in the XP browsers I tried.
I gotta find a better server to put this stuff on.
> It is strange though because on the
> first two clicks I see no activity, on the third click i see
> "Downloading blah blah blah" in the status bar but when it finishes
> downloading I don't see the alert. I think the other tests are working
> but maybe you can look again before I click about 100 times in 20
> browsers.
I think that is more AOCrap's server than anything else.
> Off topic but what is the difference with putting urls in <URL: > vs.
> just in <> like VK suggested?
Two tests:
<URL:
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/methods/close_0.asp>
<http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/methods/close_0.asp>
Easy enough to test. Let's see what the difference is with a long URL.
Peter Michaux
> >
> > Randy Webb wrote:
> >> <URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/>
> >
> > Is this file really working?
>
> I can verify that my local copy works. As for the online copy, I can't
> even get the nice wonderful AOL server to even serve me the file to test
> it :\
>
> After testing it with the full filename it seems to be loading it for me
> now in Opera 9.0 and all of the buttons work as designed.
>
> I emailed you all the files it uses. If it fails to send the files for
> some reason, let me know and I will post a .zip file somewhere.
The attachments didn't come through on the email. I tried to reply to
you but the AOL postmaster says
<<< 550 hikksnotathome IS NOT ACCEPTING MAIL FROM THIS SENDER
> > Now I'm getting all failures on the first test in the XP browsers I tried.
>
> I gotta find a better server to put this stuff on.
If you can post a zipped file I will put it up on my server.
> > It is strange though because on the
> > first two clicks I see no activity, on the third click i see
> > "Downloading blah blah blah" in the status bar but when it finishes
> > downloading I don't see the alert. I think the other tests are working
> > but maybe you can look again before I click about 100 times in 20
> > browsers.
>
> I think that is more AOCrap's server than anything else.
The download times have been slow all along but this strange behavior
is new since you added the last two columns. I don't know what's up but
if you post the zip I imagine all will work.
Peter
Randy Webb
> Randy Webb wrote:
>>> Randy Webb wrote:
>>>> <URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/>
>>> Is this file really working?
>> I can verify that my local copy works. As for the online copy, I can't
>> even get the nice wonderful AOL server to even serve me the file to test
>> it :\
>>
>> After testing it with the full filename it seems to be loading it for me
>> now in Opera 9.0 and all of the buttons work as designed.
>>
>> I emailed you all the files it uses. If it fails to send the files for
>> some reason, let me know and I will post a .zip file somewhere.
>
> The attachments didn't come through on the email. I tried to reply to
> you but the AOL postmaster says
>
> <<< 550 hikksnotathome IS NOT ACCEPTING MAIL FROM THIS SENDER
The email address on this post is indeed blocked. The email address to
use is the one in the FAQ for me. It is in the very last section of the FAQ.
>
>>> Now I'm getting all failures on the first test in the XP browsers I tried.
>> I gotta find a better server to put this stuff on.
>
> If you can post a zipped file I will put it up on my server.
<URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/index.zip>
If it doesn't work, let me know.
>>> It is strange though because on the
>>> first two clicks I see no activity, on the third click i see
>>> "Downloading blah blah blah" in the status bar but when it finishes
>>> downloading I don't see the alert. I think the other tests are working
>>> but maybe you can look again before I click about 100 times in 20
>>> browsers.
>> I think that is more AOCrap's server than anything else.
>
> The download times have been slow all along but this strange behavior
> is new since you added the last two columns. I don't know what's up but
> if you post the zip I imagine all will work.
Not sure why adding the last two columns would cause the first three to
stop working as nothing was changed in the code for the first three
columns as far as buttons are concerned.
Peter Michaux
> > If you can post a zipped file I will put it up on my server.
>
> <URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/index.zip>
>
I put it up here
<URL: http://peter.michaux.ca/temp/loadJSFile/loadJSFile.html>
It seems to be working more normally.The first column test is working
on the first click in IE5 and IE6 again.
I have 18 hours in the Los Angeles airport to kill. I'll probably find
some time to click a few tests :/
Peter
Randy Webb
I spent 6 hours in the Las Vegas Airport before spending 4 hours in the
Atlanta airport Tuesday so I can empathize with you. Better you than me
though :)
Peter Michaux
[Re: createTextNode and script insertion]
> I put it up here
>
> <URL: http://peter.michaux.ca/temp/loadJSFile/loadJSFile.html>
Below are my results for the XP and OS X 10.4.8 browsers I have. I
tried to be very careful with version numbers. I can test 10.3 browsers
(Mac/IE 5.2 and Safari 1.3.9) in a couple days. It might be interesting
to add NN6.2.1, 6.2.2, 6.2.3 to see when the innerHTML stopped running
script elements <URL: http://sillydog.org/narchive/full67.php>
It looks like IE4 (no XHR) and iCab 3 (no mass popularity) are the only
lost causes for script insertion. A couple strange Opera results I
noticed too.
Peter
<tr>
<td class="PC" width="160px">IE4.0</td>
<td class="PC" width="110px">Win XP</td>
<td class="no" width="120px">button doesn't animate click</td>
<td class="no" width="120px">button doesn't animate click</td>
<td class="no" width="120px">button doesn't animate click</td>
<td class="no" width="140px">No</td>
<td class="no" width="140px">No</td>
</tr>
<tr>
<td class="PC">IE5.01</td>
<td class="PC">Win XP</td>
<td class="yes">Yes</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td class="no">No</td>
</tr>
<tr>
<td class="PC">IE5.5sp2</td>
<td class="PC">Win XP</td>
<td class="yes">Yes</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td class="no">No</td>
</tr>
<tr>
<td class="PC">IE6.0</td>
<td class="PC">Win XP</td>
<td class="yes">Yes</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td class="no">No</td>
</tr>
<tr>
<td class="PC">Opera 8.0</td>
<td class="PC">Win XP</td>
<td class="yes">Yes</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="yes">Yes (two identical and consecutive alert boxes)</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="PC">Opera 7.52</td>
<td class="PC">Win XP</td>
<td class="yes">Yes (only works on first click)</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="PC">Firefox 1.0</td>
<td class="PC">Win XP</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="PC">Netscape 8.0.4</td>
<td class="PC">Win XP</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="PC">Netscape 7.0</td>
<td class="PC">Win XP</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="PC">Netscape 6.2</td>
<td class="PC">Win XP</td>
<td class="no">No</td>
<td class="no">yes</td>
<td class="no">yes</td>
<td class="no">yes</td>
<td class="no">yes</td>
</tr>
<tr>
<td class="PC">Netscape 6.1</td>
<td class="PC">Win XP</td>
<td class="no">No</td>
<td class="no">yes</td>
<td class="no">yes</td>
<td class="no">yes</td>
<td class="no">yes</td>
</tr>
<tr>
<td class="PC">Netscape 6.0</td>
<td class="PC">Win XP</td>
<td class="no">No</td>
<td class="no">yes</td>
<td class="no">yes</td>
<td class="no">yes</td>
<td class="no">yes</td>
</tr>
<tr>
<td class="MAC">Safari 2.0.4</td>
<td class="MAC">MacOS 10.4.8</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="no">No</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="MAC">Camino 1.0.3</td>
<td class="MAC">MacOS 10.4.8</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="MAC">Opera 9.02</td>
<td class="MAC">MacOS 10.4.8</td>
<td class="yes">Yes</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="MAC">Shiira 1.2.2</td>
<td class="MAC">MacOS 10.4.8</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="no">No</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="MAC">Sunrise 0.89</td>
<td class="MAC">MacOS 10.4.8</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="no">No</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="MAC">Firefox 2.0</td>
<td class="MAC">MacOS 10.4.8</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="MAC">Firefox 1.5.0.8</td>
<td class="MAC">MacOS 10.4.8</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="MAC">Firefox 1.0</td>
<td class="MAC">MacOS 10.4.8</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="MAC">iCab 3.0.3 </td>
<td class="MAC">MacOS 10.4.8</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td class="yes">Yes</td>
<td class="no">No</td>
<td class="no">No</td>
</tr>
Randy Webb
> Peter Michaux wrote:
>
> [Re: createTextNode and script insertion]
>
>> I put it up here
>>
>> <URL: http://peter.michaux.ca/temp/loadJSFile/loadJSFile.html>
>
> Below are my results for the XP and OS X 10.4.8 browsers I have. I
> tried to be very careful with version numbers. I can test 10.3 browsers
> (Mac/IE 5.2 and Safari 1.3.9) in a couple days. It might be interesting
> to add NN6.2.1, 6.2.2, 6.2.3 to see when the innerHTML stopped running
> script elements <URL: http://sillydog.org/narchive/full67.php>
innerHTML stopped changing it in 7.0PR1,
Results:
Netscape 7.0PR1 Win XP No No Yes Yes Yes
Netscape 6.2.3 Win XP No Yes Yes Yes Yes
Netscape 6.2.2 Win XP No Yes Yes Yes Yes
Netscape 6.2.1 Win XP No Yes Yes Yes Yes
Netscape 6.2.1 Win XP No Yes Yes Yes Yes
Netscape 6.1 Win XP No Yes Yes Yes Yes
Netscape 6.0.1 Win XP No No No No No
Netscape 6.0 Win XP No No No No No
Yes, I was extremely bored. Just don't ask me which versions support XHR
- I won't go through that again to find out :)
> It looks like IE4 (no XHR) and iCab 3 (no mass popularity) are the only
> lost causes for script insertion. A couple strange Opera results I
> noticed too.
I retested it in my O7.54 and got the same results of it only working
the first time.
> <tr>
> <td class="PC">Opera 8.0</td>
> <td class="PC">Win XP</td>
> <td class="yes">Yes</td>
> <td class="no">No</td>
> <td class="yes">Yes</td>
> <td class="yes">Yes (two identical and consecutive alert boxes)</td>
> <td class="yes">Yes</td>
Duplicated in 8.01 I think what it is doing is executing it when you set
.text and then again when you appendChild the script block. Have to test
it later after sleep and find out.
> </tr>
> <tr>
> <td class="PC">Opera 7.52</td>
> <td class="PC">Win XP</td>
> <td class="yes">Yes (only works on first click)</td>
Duplicated in 7.54
I have an updated index file for this that covers the NS6-8 browsers
along with the additional test results that I will get uploaded later
this afternoon if AOL will cooperate with me.
Peter Michaux
Randy Webb wrote:
> innerHTML stopped changing it in 7.0PR1,
>
> Results:
>
> Netscape 7.0PR1 Win XP No No Yes Yes Yes
> Netscape 6.2.3 Win XP No Yes Yes Yes Yes
> Netscape 6.2.2 Win XP No Yes Yes Yes Yes
> Netscape 6.2.1 Win XP No Yes Yes Yes Yes
> Netscape 6.2.1 Win XP No Yes Yes Yes Yes
without the ".1", I imagine.
> Netscape 6.1 Win XP No Yes Yes Yes Yes
> Netscape 6.0.1 Win XP No No No No No
> Netscape 6.0 Win XP No No No No No
>
> Yes, I was extremely bored. Just don't ask me which versions support XHR
> - I won't go through that again to find out :)
You can always check the group FAQ :)
<URL: http://jibbering.com/faq/newfaq/#FAQ4_34>
To figure that out for the FAQ, I tested 6.0, 6.1 and 6.2 and assume
following point releases of 6.2 have XHR also.
Peter
Randy Webb
> Randy Webb wrote:
<snip>
>> Yes, I was extremely bored. Just don't ask me which versions support XHR
>> - I won't go through that again to find out :)
>
> You can always check the group FAQ :)
>
> <URL: http://jibbering.com/faq/newfaq/#FAQ4_34>
I could, but I am not sure I trust the guy that maintains that document,
I hear he is kinda strange with a warped sense of humor <g>
Peter Michaux
> Peter Michaux wrote:
>
> [Re: createTextNode and script insertion]
>
> > I put it up here
> >
> > <URL: http://peter.michaux.ca/temp/loadJSFile/loadJSFile.html>
>
Below are my results for two older Mac browsers.
Randy, what will you make of all these results? Will you upload a
summary?
Peter
<tr>
<td class="MAC">Safari 1.3.2</td>
<td class="MAC">OS X 10.3.9</td>
<td class="no">No</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="no">No</td>
<td class="yes">Yes</td>
</tr>
<tr>
<td class="MAC">IE 5.2</td>
<td class="MAC">OS X 10.3.9</td>
<td class="no">No</td>
<td class="yes">Yes</td>
<td class="no">No</td>
Randy Webb
> Peter Michaux ha escrito:
>
>> Peter Michaux wrote:
>>
>> [Re: createTextNode and script insertion]
>>
>>> I put it up here
>>>
>>> <URL: http://peter.michaux.ca/temp/loadJSFile/loadJSFile.html>
>
> Below are my results for two older Mac browsers.
>
> Randy, what will you make of all these results?
I think the biggest thing it does is give a reference point so that if
someone is testing and wants to insert scripts it is a place to look it
up and see if it is known - or not - whether it works in a particular
OS/Browser combination.
> Will you upload a summary?
About the only summary I can think of for it would be an article
(perhaps for the Notes section of the FAQ) on loading JS files and
inserting script blocks dynamically and where it does/doesn't work.
Probably some type of FAQ question along the lines of "Why doesn't my
script get executed when it is inserted after an AJAX request?" type
question. It is what I alluded to when I said I saw it coming and was
trying to stay ahead of the curve on it.
01075423093강남홀덤
> Randy Webb wrote:
> > Simple scenario. Let's say a page is loaded via XHR.
> Maybe this is just semantics but folks don't usually load a page with
> XHR but rather an HTML snip that may contain script blocks.
> > The biggest thing? I hate eval :)
> but Randy, eval is the only way to write dynamic code like this...
> eval("myObj." + foo + "=" + bar);
> :-) Ok. Seriously...
> I haven't run tests, but as far as I know, eval is the quickest way to
> parse trusted json. The alternative is a relatively lengthy json parser
> written in JavaScript.
> > Three years ago you didn't see questions in this group with
> > regards to XMLHttpRequest and/or AJAX very often. Now, you see a
> > kazillion of them. The next phase of that, to me, is going to be script
> > issues and it is already happening where people are asking "How do I
> > make my scripts execute when loaded with AJAX" and I am simply trying to
> > be ahead of it and come up with an answer before the onslaught happens.
> This attitude plus FAQ mantainer: a true humanitarian!
> > Personally, I don't use AJAX to load data. What dictates how you load
> > data is how your back end is set up. People seem to think that you can
> > simply take a huge site and convert it to AJAX and everything keeps
> > going when that isn't true. If you have a site that has, say, 100 pages
> > to it. OK, lets make it an AJAX site. Create a new first page, use AJAX
> > to load the other pages and drop them in a div container. Simple, and
> > you now have an "AJAX site". That is what it seems a lot of people are
> > doing and it runs into the "My scripts don't execute" scenario. Where if
> > the site is setup and maintained to be an AJAX driven site then the
> > "pages" aren't complete HTML pages and don't stand on there own.
> >
> > The approach I use, and prefer, for loading data is .js files and
> > loading them on the fly. The back end still has to be set up to create
> > those .js files and the main page is set up to handle it. I just find
> > the .js files simpler and more reliable than AJAX is all.
> But once a site starts submitting forms with Ajax then the whole site
> may as well switch over to Ajax all together, don't you think?
> Peter
우리카지노계열은 메리트카지노, 더킹카지노,샌즈카지노,코인카지노,더나인카지노,007카지노,퍼스트카지노 가 현재 운영이 되고 있습니다.
에볼루션라이트닝카지노
에볼루션라이트닝카지노 (Evolution Lightning Casino)는 2006년에 열리자 마자 룰렛, 블랙잭 및 바카라를 제공하는 유럽 라이브 딜러 비디오 플랫폼의 새로운 물결이 일어났습니다.
cleo_casino 안전하게 이용하시려면 제 홈페이지에 등록된 배너를 클릭하여 가입하시면 됩니다.https://xvccknjfsecvk.wixsite.com/wooricasinos