I have read all the reason why DOM purists don't like document.write
and innerHTML. I would like to be a good programmer and do the right
thing and not use them. But I need your help to get it to what the
project needs done.
In the interest of brevity, the following code has been simplified.
You'll notice sDoc contains HTML and JavaScript, this is a
unchangeable requirement. PLEASE don't waste your time or mine by
explaining how un-couth it is. I know it is but there's nothing I can
do about. Answers strictly focused what can be done versus what should
be done will be greatly appreciated.
There are three attempted methods to render the sDoc. The first one is
to create a textNode and append it to a div. It prints the code as
text instead of rendering it, as expected. Is it possible to get it to
render?
The second method uses innerHTML and the HTML is rendered but not the
JavasScript.
The third method uses document.write which renders both the HTML and
JavaScript, but we really really don't want to use the write method,
but at this point it looks like we have no choice.
We've even tried to render sDoc in a DOM created iFrame, but it chokes
in Mozilla browsers because of the known bug of included scripts that
use document.write (once again another requirement that can't be
changed) kills the page as document.close fails.
<div id="foo1" style="border:1px solid black;"></div>
<div id="foo2" style="border:1px solid black;"></div>
<script type="text/javascript">
var sDoc = '<center><scr'+'ipt
language=javascript>alert(true);</scr'+'ipt></center>';
var myText = document.createTextNode(sDoc);
document.getElementById("foo1").appendChild(myText);
document.getElementById("foo2").innerHTML = sDoc;
document.write(sDoc);
</script>
Thank you for your consideration.
OK
> In the interest of brevity, the following code has been simplified.
> You'll notice sDoc contains HTML and JavaScript, this is a
> unchangeable requirement. PLEASE don't waste your time or mine by
> explaining how un-couth it is.
So "I want to hear about right things but I don't give a damn that you
may say as in any case I'll keep doing the stuff in the way I'm
accustomed to".
OK, I personally will not waste no one's time as suggested. :-) :-|
P.S. If it was a polemic post to state your own position on the topic
then you could at least choose something lesser bizarre than
> var sDoc = '<center><scr'+'ipt
> language=javascript>alert(true);</scr'+'ipt></center>';
A <script> tag centered by using ancient Netscape <center> tag? What in
the name does it suppose to mean? If it's a real extract from one of
your pages then you have much more serious problems than any dynamic
content generation. If you just made it up in a polemic excitement then
it would help to see a real life case.
Let me make the question very simple: YES or NO can DOM accomplish
what write accomplishes with the string of HTML and JavaScript AS IT
IS!?!
I've got $20 dollars riding on an office bet this very simple question
won't get answered with a simple "no it can't be done" or "yes, even
with that mangled string you can GET IT TO WORK, if you did this..."
Come on guys and girls, make me lose my money.
As far as I know, the only appropriate way to write a string to a
document via DOM methodology is to create a text node
(document.createTextNode(string)) and append it to an existing node.
createTextNode resolves HTML entities, so your '<script>' ends up as
'<script>'.
I would have thought that innerHTML might work, but I have not tested
it and it sounds like it doesn't according to your description. There
are of course other methods, but as these are not options for you, then
NO is the answer as far as I know.
As well as you couldn't resist to place "<center>" tag in your code, is
not it? ;-)
> Let me make the question very simple: YES or NO can DOM accomplish
> what write accomplishes with the string of HTML and JavaScript AS IT
> IS!?!
NO. The proposed bizarrity can be accomplished only by a very bizarre
way. One is already found by you, so I see no reason to search for more
- even if there are any.
You've just saved your twenty bucks I guess.
As I don't like to loose I have a contre bet to you:
I have $40 to pay if you pass your right hand behind your head and you
scratch by this hand your right ear. Send a photo with the address for
the money transfer to my e-mail.
:-)
> Let me make the question very simple: YES or NO can DOM accomplish
> what write accomplishes with the string of HTML and JavaScript AS IT
> IS!?!
>
> I've got $20 dollars riding on an office bet this very simple question
> won't get answered with a simple "no it can't be done" or "yes, even
> with that mangled string you can GET IT TO WORK, if you did this..."
If you want to set innerHTML and want script execution then IE documents
that you need to set the defer attribute on the script element e.g.
<script type="text/javascript defer></script>
see
<http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/properties/innerhtml.asp>
Nevertheless it is not reliable for all cases, putting real HTML content
first and then the script element seems to increase the chances to have
both the content rendered and the script executed.
Mozilla and Opera don't execute script when you set innerHTML I think
but they do if you insert a script element with the W3C DOM (e.g.
appendChild, insertBefore, replaceChild) into the document.
So with innerHTML you can serve IE and Mozilla and Opera if you have a
container element, clone that, set innerHTML on that clone before it is
inserted in the document, then finally replace the original container
element with the clone (e.g. element.parentNode.replaceChild(clone,
element)). And the script element for IE needs the defer attribute.
This test case
<http://home.arcor.de/martin.honnen/javascript/2006/11/test2006110201.html>
works for me on Windows XP with Opera 8.5, 9.0, Firefox 2.0, SeaMonkey
1.0, and IE 6 where "works" means that both inserted scripts are
executed, the alert directly when the insert operation happens, the
function test is parsed and available as clicking the text executes the
function correctly and inserts the date/time when clicked.
But there are other browsers (e.g. Safari, Konqueror) that might need
other attempts so generally inserting script with innerHTML is not reliable.
--
Martin Honnen
http://JavaScript.FAQTs.com/
What is your e-mail ?
If it's OK with left hand and ear,
I'll give you my PayPal for the $400 transfer to me.
You lose your money.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
> NO. The proposed bizarrity can be accomplished only by a very bizarre
> way. One is already found by you, so I see no reason to search for more
> - even if there are any.
OK... I just came from some meeting. Is it about that EOLAS? If it is
then here is the code and sorry for joking. If it is *not* about that
EOLAS that you are not allowed to use it - I will not check of course
but it will be a stollen software usage.
Even if it is about EOLAS you do it in an overly hard way. There are
much nicer and still DOM-compliant workarounds. But as I'm still
running for my $20 :-) here is the solition exactly as spelled:
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body>
<div id="screwThem"></div>
<script type="text/javascript">
/* anti-EOLAS usage welcome */
/* any other usage is prohibited */
var out = document.getElementById('screwThem');
if (out) {
var HTMLFragment = document.createElement('div');
HTMLFragment.id = 'dyn001';
HTMLFragment.innerHTML = '<b>Bold text</b>';
HTMLFragment.style.border = 'thin solid black';
out.appendChild(HTMLFragment);
var JSBlock = document.createElement('script');
JSBlock.type = 'text/javascript';
JSBlock.text = 'window.alert("Hi!");';
out.appendChild(JSBlock);
}
</script>
<div>The rest of page</div>
</body>
</html>
I never thought I would see you claim code that you learned here to be
yours and under copyright protection. Creating elements on the fly is
old news (about 5 years old).
first of all, I did not learn this code here but I wrote it right off
my head while answering.
secondly it is not copyrighted, use this however you want, but anything
except EOLAS would be programming logic (and the conventional logic)
abuse so I would be upset seeing my code used for just dynamic page
updates. this is what I wanted to say by my notice. There is not (c)
sign in there.
and the last but not least it uses scriptElement.text property, not
createTextNode or appendChild. A small details but it makes it work on
IE6, Opera9, FF1.5 (this is what I had time to check).
forthly I just checked the entire archives and createJSFile you
suggested to look for in another thread exists only in one post: namely
in your own one where you are suggesting to look for it.
You must be confused with numerous dynamic *external* script topics
discussed here in another NG.
For the *inline* scripts the solution did not exist because everyone
was trying to use the road over createTextNode method and it doesn't
work for IE (though seems to work for Firefox).
scriptObject.text = "sctring to execute" works universally on all UA's
anyone should be bothered about and I've found it in lesser than in 4
min.
That is again *not* about copyrights of any kind, feel free to use; but
as myself I'm a very cautious man in (c) issues I would like to
eliminate any misunderstanding on the matter.
P.S. To side readers if they are wondering what a hell EOLAS is and why
does it suck so badly: see for instance
<http://news.com.com/2009-1023_3-5082004.html>
Your code below doesn't work with my Safari :-(
(it doesn't more with my IE Mac but I knew it)
Doesn't work with iCab :-(
Alone FF and Opera can understand it.
I'd like to buy all of you beer, but big thanks to Martin for coming
up with killer workaround code. I'll tinker with it now and post a
message if I have a question.
Until then, code on.
I said: "on all UA's anyone should be bothered about". Neither Safari
1.x nor iCab in that list :-(
Safari _2.x_ did a big step forward from a beautiful yet useless
application canvas to a real web-browser. Still long way to go, but at
least this baby does seem totally hopeless as it did before. We'll see
the development. For the time being for a serious browsing on modern
Mac's Camino <http://www.caminobrowser.org> remains the preferred
choice ("at least Mac OS X 10.2" is not too much to ask IMHO at the end
of the year 2006).
iCab, IE Windows 3.x (plus Trumpets patch of course), NCSA Mosaic x.x,
Lynx for MS-DOS etc. are great tools for a hardware museum to let
visitors at least to take a look at the modern Internet using PC XT,
Macintosh prototypes and other museum items. I don't see though how it
would affect on the current web-development approaches ?
Indeed, the name of the function is loadJSFile instead of createJSFile.
> You must be confused with numerous dynamic *external* script topics
> discussed here in another NG.
In "another NG" or another thread?
> For the *inline* scripts the solution did not exist because everyone
> was trying to use the road over createTextNode method and it doesn't
> work for IE (though seems to work for Firefox).
No, not "everybody". If you follow the loadJSFile search you will get to
this thread:
In fact, that is the first thread in the search of the archives for
loadJSFile.
Where I modified the loadJSFile function to set the .text property.
Setting the .text property of a script element is old news VK.
> scriptObject.text = "sctring to execute" works universally on all UA's
> anyone should be bothered about and I've found it in lesser than in 4
> min.
Ahh, the VK "UA anyone should be bothered about". Can you give a
comprehensive list of modern UA's? I bet you can't. Hell, double or
nothing on the 20 dollars you have already lost.
> That is again *not* about copyrights of any kind, feel free to use; but
> as myself I'm a very cautious man in (c) issues I would like to
> eliminate any misunderstanding on the matter.
Anything you have to say is generally a misunderstanding so I don't
think you have to worry about that.
That's much better: the link is found, your priority is confirmed :-)
- though I indeed just saw it for the first time.
> Ahh, the VK "UA anyone should be bothered about". Can you give a
> comprehensive list of modern UA's? I bet you can't.
A list of UA's anyone should check against for particularities before
releasing a solution? A list anyone would agree on? You must be
kidding. Even if Holy Mary would come here with such list she would
have to run away in one minute: saving herself from a stream of
profanities.
I can only name the UA's considered monetary important to check
against: by myself and by the small outsourced company I'm running.
These are:
IE 6.0 SP1
IE 7.0
Firefox 1.5
Camino 1.0.3
+ UA's used by CEO and CFO of the company placing the order (if not in
the list).
The latter is the most important one after IE 6.0, I'm always trying to
find a reason (portfolio demonstration is a good one) to check if there
is something "conceptual" in there.
There are also "sport vehicle" UA's, it means I bother to look at them
if I have some free time and nothing better to do. These are:
Opera 9.02
Netscape 8.1.2 (majorly for nostalgic issues, so besides free time it
has to be a rainy day and a bad mood).
Also I have W3C Amaya 8.8.51
That one for laughing and overall to cheer up. Also from time to time
I'm using its SVG editor.
That I don't doubt (you seeing it for the first time).
>> Ahh, the VK "UA anyone should be bothered about". Can you give a
>> comprehensive list of modern UA's? I bet you can't.
>
> A list of UA's anyone should check against for particularities before
> releasing a solution? A list anyone would agree on? You must be
> kidding.
But you alluded to "Any UA anyone should be bothered about" and to be
able to say that you must have some criteria that a UA must meet to be
included in that list.
> Even if Holy Mary would come here with such list she would
> have to run away in one minute: saving herself from a stream of
> profanities.
Precisely my point.
> I can only name the UA's considered monetary important to check
> against: by myself and by the small outsourced company I'm running.
> These are:
> IE 6.0 SP1
> IE 7.0
> Firefox 1.5
You may want to update that to FF2.0
> Camino 1.0.3
> + UA's used by CEO and CFO of the company placing the order (if not in
> the list).
And how do you determine that? Ask them or browser detection? Think
about that one.
> The latter is the most important one after IE 6.0, I'm always trying to
> find a reason (portfolio demonstration is a good one) to check if there
> is something "conceptual" in there.
The latter should be the first one on your list if you are trying to
please the people signing the check.
Comprehensive list? Any browser/UA that will support what you are trying
to do. And you determine that list via object detection and you don't
care what the browser/UA is.
> There are also "sport vehicle" UA's, it means I bother to look at them
> if I have some free time and nothing better to do. These are:
> Opera 9.02
> Netscape 8.1.2 (majorly for nostalgic issues, so besides free time it
> has to be a rainy day and a bad mood).
NS8 is built on the IE engine and the Mozilla engine so testing in
Mozilla and IE *should* satisfy NS8.