Dynamic Script Insertion Revisited

Randy Webb wrote:
> Richard Cornford said the following on 8/8/2007 7:01 PM:
>> Randy Webb wrote:
>> <snip>
>>> The problem was, and still is, that IE - no version -
>>> will allow you to use createTextNode and then
>>> appendChild it to a Script element.
>> <snip>
>>
>> Internet Explorer Elements have a boolean - canHaveChildren -
>> property.
>
> Is IE the only one that implements canHaveChildren?

It is the only one I have noticed, but some manufacturers strive to
imitate IE and if they notice that the property exists they may well
reproduce it, but whilst doing so may not restrict the ability of the
script element to have children.

>> For script elements it has a false value. It doesn't represent
>> the whole solution but I would think that if you found that a
>> script element had a - canHaveChildren - property of boolean
>> type, and that it was false, then attempting to add child nodes
>> of any sort would look line a non-viable activity.
>
> if ((typeof(newScript.canHaveChildren) === 'boolean') &&
> (newScript.canHaveChildren === false))

Having verified that the property is of boolean type I would not bother
with the comparison in the second test. Just NOT - canHaveChildren -
would do.

> I don't think a test to see if it is false or not would be
> required but probably wouldn't hurt to include

I would say that the second test is necessary to complete the logic of
the test.

> it just in case some other browser is out or comes out that implements
> canHaveChildren.

And that as well.

> I have it noted in a Notes file I have on script insertion
> so that I can go back to it and give it some more thought later.
<snip>

If I had time to look at this properly I might look at putting a script
element on a page that had code contents and then examining it to see
what type of children it did have (if any). If Text node(s) then that
may be good grounds for particular actions. Though logically you could
suspect that some would (or may) have CDATASection nodes (nodeType ==
4), given that in HTML the contents of a scirpt are interpreted as
CDATA.

Richard.

On Aug 9, 2:21 am, David Mark <dmark.cins....RemoveThis@gmail.com> wrote:
> On Aug 8, 10:28 pm, Randy Webb <HikksNotAtH....RemoveThis@aol.com> wrote:
>
> > David Mark said the following on 8/8/2007 9:32 PM:
>
> > > On Aug 8, 8:27 pm, Randy Webb <HikksNotAtH....RemoveThis@aol.com> wrote:
>
> [snip]
>
>
>
> > Thanks for the input and insight.
>
> No problem. I was sufficiently intrigued by this problem that I gave
> it another go with the third branch included.

Oops. I just realized that my window.onerror afterthought has a
flaw. It should define the executeJSString the same as if all three
tests fail (and put the old error handler back.) And of course, if
one of the three fail with an error (something I tried to avoid with
feature detection throughout), the other tests won't be tried.

The only real value of the window.onerror handler in this example is
to prevent a script error from being reported to the user. The
alternative of using try/catch clauses for the tests you think might
cause an error (and putting the whole thing in its own file) is
looking like a better idea.