innerHTML and JavaScript

[bjorn2k]

Hi all,

I'm trying to generate client-side javascript with client-side
javascript. I'm doing this using innerHTML.

Example:
Let's say i have variable called text. I fill this with a string
something like: <script type="text/javascript">Some JavaScript</script>

And then i do the following:
document.getElementById('someid').innerHTML = text;

Why isn't this working?

greetz Bjorn

[Jonas Raoni]

> I'm trying to generate client-side javascript with client-side

javascript. I'm doing this using innerHTML.

It sounds strange, everything can be made by using some functions and
arguments, are you sure of what you're doing?

Anyway, try the above, I just tested on IE, FF and Opera...

var s = document.createElement("script");
s.type = "text/javascript";
s.text = "alert('jonas');";
document.body.appendChild(s);
--
"Invente, Tente!!! Faça um código eficiente" (eu)

Jonas Raoni Soares Silva
---------------------------
jonasraoni at gmail dot com
http://www.jsfromhell.com

[Thomas 'PointedEars' Lahn]

Jonas Raoni wrote:

I'm trying to generate client-side javascript with client-side
javascript. I'm doing this using innerHTML.
It sounds strange, everything can be made by using some functions
and arguments, are you sure of what you're doing?

Anyway, try the above, I just tested on IE, FF and Opera...

With the numerous version of those UAs around, that can mean anything
-- or nothing.
var s = document.createElement("script");
s.type = "text/javascript";
s.text = "alert('jonas');";
document.body.appendChild(s);

Does not work reliably.

<URL:http://pointedears.de/scripts/test/whatami#inference>
PointedEars

[Jonas Raoni]

Thomas 'PointedEars' Lahn escreveu:

With the numerous version of those UAs around, that can mean anything
-- or nothing.
Creating JavaScript that way sounds strange... There's always another
way out to do things...
Does not work reliably.

JavaScript is evil and should be the last thing to be done on a site,
after everything is already working... This might solve part of the
problems...
--
"Invente, Tente!!! Faça um código eficiente" (eu)

Jonas Raoni Soares Silva
---------------------------
jonasraoni at gmail dot com
http://www.jsfromhell.com

[Thomas 'PointedEars' Lahn]

Jonas Raoni wrote:

Thomas 'PointedEars' Lahn escreveu:

With the numerous version of those UAs around, that can mean anything
-- or nothing.
Creating JavaScript that way sounds strange... There's always another
way out to do things...

I am not so sure that there is _always_ another way. In fact, I can
think of features that cannot be implemented without scripting. It
is safe to say that I would try to pursue other approaches first here.

Does not work reliably.

JavaScript is evil

Do you really expect me to agree on that, here?
and should be the last thing to be done on a site,
after everything is already working...
True. Which does not make it evil in any way per se.

All generalizations are wrong ;-)
This might solve part of the problems...

No, the DOM features required are not part of the programming languages
used to access them. So they do not work everywhere, and there is no
specification or reference material on what should happen with script
content that is included after the document was parsed.
PointedEars

[Jonas Raoni]

Thomas 'PointedEars' Lahn escreveu:

Jonas Raoni wrote:

JavaScript is evil Do you really expect me to agree on that, here?

I really don't expect it haha, because if you're here, it's because you
have problems or because you like the language, I think it's the second
option ;]

You didn't understood what I meant to say... I like JS, it's really
good and solve my problems really fast, when I have something complex
to solve, I always make it using JS, since it's faster to code and
debug, besides the fact that it doesn't need compilation :)

When I say that it's evil, it's because nothing should depend on it to
work... But if well used, it's always a plus... Besides that, I think
it's a perfect language to be used on plugins development
[http://www.google.com/apis/homepage], since a lot of people know it
and it's quite easy and fast to learn :]

This might solve part of the problems...

No, the DOM features required are not part of the programming languages
used to access them.

I know, there are DOM implementations for java, pascal, php,... It's
just another data structure...

"This might solve part of the problems", you didn't understood what I
meant to say again... I'm not talking about DOM, but generally... On
the web JS should be the last thing to be written, I know you know
it...

ex: Instead of writing (a lot of people still writing such things...):
<input type="button" onclick="if(validate()) this.form.submit()"...

You should write:
addEvent(form, "submit", ....

This (leaving the js for the end...) really might solve part of the
problems :)

So they do not work everywhere
It's true, but using or not new features is a dilema that I don't know
the correct answer... Sometimes it isn't possible to make the code work
everywhere, and sometimes doing this produces really ugly code... I
just test my things on Opera, FF and IE... ;]

So, if it's not required to make a very compatible code, I use the new
features with no regrets... If it doesn't work on mobile, tv, etc.
browsers, it's because they should be upgraded (instead of downgrade my
code) :D
and there is no specification or reference material on what should happen
with script content that is included after the document was parsed.

In my opinion the content should be parsed, but my opinion doesn't
matter :)

This thread is already out of scope :D
--
Jonas Raoni Soares Silva
http://www.jsfromhell.com

[Thomas 'PointedEars' Lahn]

Jonas Raoni wrote:

Thomas 'PointedEars' Lahn escreveu:

Jonas Raoni wrote:

> JavaScript is evil Do you really expect me to agree on that, here?

I really don't expect it haha,

You know, posting something like "haha" within a sentence, especially in a
technical newsgroup, does not make you look very intelligent. You might
want to consider stopping that.
because if you're here, it's because you have problems or because you
like the language, I think it's the second option ;]
It is the second option instead of the first one that applies to be most of
the time.
You didn't understood what I meant to say... I like JS, it's really
good and solve my problems really fast, when I have something complex
to solve, I always make it using JS, since it's faster to code and
debug, besides the fact that it doesn't need compilation :)
JS code is compiled to byte-code before that is interpreted by a VM.
There is no difference to Java here.
When I say that it's evil, it's because nothing should depend on it to
work... But if well used, it's always a plus...
Labeling something "evil" is usually a way of saying that using it is not
generally recommended [compare: "evil[tm] eval()"] . You might want to
reconsider your terminology.
Besides that, I think it's a perfect language to be used on plugins
development [http://www.google.com/apis/homepage], since a lot of people
know it and it's quite easy and fast to learn :]
Obviously you do not know what a plugin is.

> This might solve part of the problems...

No, the DOM features required are not part of the programming languages
used to access them.

I know, there are DOM implementations for java, pascal, php,... It's
just another data structure...

The languages I was talking about are ECMAScript and its implementations,
particularly JavaScript and JScript. The DOM features required here are
not part of either of those languages; instead, the DOM implementation is
UA-dependent.
This (leaving the js for the end...) really might solve part of the
problems :)
Using scripting here introduces more problems than it could possibly solve.

So they do not work everywhere

It's true, but using or not new features is a dilema that I don't know
the correct answer...

At least "new" features should be feature-tested for on runtime. Not even
this happens here. <URL:http://pointedears.de/scripts/test/whatami>
So, if it's not required to make a very compatible code, I use the new
features with no regrets... If it doesn't work on mobile, tv, etc.
browsers, it's because they should be upgraded (instead of downgrade my
code) :D

You do not have to look that far. IE 4.0 or any other user agent for PC/Mac
not implementing these features of the W3C DOM or not implementing them in
the way it was supposed to work by the author (that includes not passing
the content of newly appended `script' elements to the script engine) would
be sufficient for "not work".
PointedEars

[Jonas Raoni]

Thomas 'PointedEars' Lahn escreveu:

Jonas Raoni wrote:

Thomas 'PointedEars' Lahn escreveu:

Jonas Raoni wrote: I really don't expect it haha,

You know, posting something like "haha" within a sentence, especially in a
technical newsgroup, does not make you look very intelligent. You might
want to consider stopping that.

First, I'm free to write the way I want =]
Second, I don't want and don't need to prove that I'm inteligent to
anyone... Don't criticize another person's level without knowing it,
the best quality of an inteligent person is to be modest...
Third, I won't stop writing "haha" and those idiot smileys just because
you don't like them :)

I always make it using JS, since it's faster to code and
debug, besides the fact that it doesn't need compilation :)

JS code is compiled to byte-code before that is interpreted by a VM.
There is no difference to Java here.

Please, stop misunderstanding what I say... It's frustating to explain
everything that I write...

"doesn't need compilation" => I mean you don't need to generate an
".exe" for example, confront AV's, etc... Just edit the code, save and
press F5...
Labeling something "evil" is usually a way of saying that using it is not
generally recommended [compare: "evil[tm] eval()"] . You might want to
reconsider your terminology.
Yeah, I'll use another word next time, English isn't my primary
language ;]

Besides that, I think it's a perfect language to be used on plugins
development [http://www.google.com/apis/homepage], since a lot of people
know it and it's quite easy and fast to learn :]

Obviously you do not know what a plugin is.

No comments for this sentence...

The languages I was talking about are ECMAScript and its implementations,
particularly JavaScript and JScript. The DOM features required here are
not part of either of those languages; instead, the DOM implementation is
UA-dependent.
Sure...

At least "new" features should be feature-tested for on runtime. Not even
this happens here. <URL:http://pointedears.de/scripts/test/whatami>
Yeah, that's the right approach...

PointedEars

Just a personal comment upon you Mr. Spock, you really should find a
girl to occupy some of your time instead of criticizing every idiot
thing that you find... I joined this group yesterday, and I see you're
always going out of topic by discussing irrelevant subjects like my
signature and the way I write =/
--
Jonas Raoni Soares Silva
http://www.jsfromhell.com

[Thomas 'PointedEars' Lahn]

Jonas Raoni wrote:

Thomas 'PointedEars' Lahn escreveu:

Jonas Raoni wrote:

> Thomas 'PointedEars' Lahn escreveu:
>> Jonas Raoni wrote:
> I really don't expect it haha,

You know, posting something like "haha" within a sentence, especially in
a technical newsgroup, does not make you look very intelligent. You
might want to consider stopping that.

First, I'm free to write the way I want =]
[...]

Sure, that was merely a recommendation. You do not have to follow it,
but you are wise to do so; unless you are deliberately making a fool
of yourself, which would be OK with me, too.

> I always make it using JS, since it's faster to code and
> debug, besides the fact that it doesn't need compilation :)

JS code is compiled to byte-code before that is interpreted by a VM.
There is no difference to Java here.

Please, stop misunderstanding what I say... It's frustating to explain
everything that I write...

"doesn't need compilation" => I mean you don't need to generate an
".exe" for example, confront AV's, etc... Just edit the code, save and
press F5...

Compilation is not and has never been restricted to creating executable
files from source code, let alone files with filename suffix ".exe". If
you do not want to be misunderstood, choose your terms more wisely and,
more important, get informed _before_ you post.

Labeling something "evil" is usually a way of saying that using it is not
generally recommended [compare: "evil[tm] eval()"] . You might want to
reconsider your terminology.

Yeah, I'll use another word next time, English isn't my primary
language ;]

Mine neither. However, there is a certain terminology among skilled
people and I learned to respect that. You should, too; it prevents
misunderstandings.

> Besides that, I think it's a perfect language to be used on plugins
> development [http://www.google.com/apis/homepage], since a lot of
> people know it and it's quite easy and fast to learn :]

Obviously you do not know what a plugin is.

No comments for this sentence...

You lose.

PointedEars

Just a personal comment upon you Mr. Spock, you really should find a
girl to occupy some of your time [...]

You lose again. But then, you "used to be a troll"
(news:11**********************@f14g2000cwb.googleg roups.com),
so one should not expect much more from you.
PointedEars, Score adjusted

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 12/22/2005 7:31 PM:

Jonas Raoni wrote:

Thomas 'PointedEars' Lahn escreveu:

Jonas Raoni wrote:

Thomas 'PointedEars' Lahn escreveu:

>Jonas Raoni wrote:

I really don't expect it haha,

You know, posting something like "haha" within a sentence, especially in
a technical newsgroup, does not make you look very intelligent. You
might want to consider stopping that.

First, I'm free to write the way I want =]
[...]

Sure, that was merely a recommendation. You do not have to follow it,
but you are wise to do so; unless you are deliberately making a fool
of yourself, which would be OK with me, too.

Coming from someone who has a very limited concept of the English
language and is posting about a person's choice of words, the first that
comes to mind is Hypocritical. Once again Thomas, if you want to be as
pedantic as you try about English, it would behoove you to endeavor to
understand what it is that you are attempting to be pedantic about.

Just a personal comment upon you Mr. Spock, you really should find a
girl to occupy some of your time [...]

You lose again. But then, you "used to be a troll"

The difference is that you still are one.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Jasen Betts]

On 2005-12-22, bj*****@hotmail.com <bj*****@hotmail.com> wrote:

Hi all,

I'm trying to generate client-side javascript with client-side
javascript. I'm doing this using innerHTML.
why not use eval?
Example:
Let's say i have variable called text. I fill this with a string
something like: <script type="text/javascript">Some JavaScript</script>

And then i do the following:
document.getElementById('someid').innerHTML = text;

Why isn't this working?

Javascript is executed and parsed as the page loads. modifying the
document after it has loaded doesn't work.

Bye.
Jasen

[Jonas Raoni]

Jasen Betts escreveu:

On 2005-12-22, bj*****@hotmail.com <bj*****@hotmail.com> wrote:

I'm trying to generate client-side javascript with client-side
javascript. I'm doing this using innerHTML.

why not use eval?

He should show us the code or tell us what he's trying to do...

I've never needed to use eval. There must be a way out if he isn't
making something like writing code on a textarea and parsing or
generating code for testing purposes, whatever...
--
Jonas Raoni Soares Silva
http://www.jsfromhell.com

[Randy Webb]

Jasen Betts said the following on 12/23/2005 1:43 AM:

On 2005-12-22, bj*****@hotmail.com <bj*****@hotmail.com> wrote:

Hi all,

I'm trying to generate client-side javascript with client-side
javascript. I'm doing this using innerHTML.

why not use eval?

Because it's worse than any other way you can try to do it.

Example:
Let's say i have variable called text. I fill this with a string
something like: <script type="text/javascript">Some JavaScript</script>

And then i do the following:
document.getElementById('someid').innerHTML = text;

Why isn't this working?

Javascript is executed and parsed as the page loads. modifying the
document after it has loaded doesn't work.

Nonsense. Modifying a page after it has loaded is the very basis of
dHTML and works quite well.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Jasen Betts]

On 2005-12-25, Randy Webb <Hi************@aol.com> wrote:

Jasen Betts said the following on 12/23/2005 1:43 AM:

On 2005-12-22, bj*****@hotmail.com <bj*****@hotmail.com> wrote:

Hi all,

I'm trying to generate client-side javascript with client-side
javascript. I'm doing this using innerHTML.

why not use eval?

Because it's worse than any other way you can try to do it.

are you saying that using the following instead of using eval
is preferable to using eval?
// evil() a candidate for "worse than eval"
//
function evil(code_to_eval){
var s = document.createElement("script");
s.type = "text/javascript";
s.innerHTML = code_to_eval;
document.body.appendChild(s);
}

and if so, why?

--

Bye.
Jasen

[Jonas Raoni]

Jasen Betts escreveu:

On 2005-12-25, Randy Webb <Hi************@aol.com> wrote:

Jasen Betts said the following on 12/23/2005 1:43 AM:

On 2005-12-22, bj*****@hotmail.com <bj*****@hotmail.com> wrote:
why not use eval?

Because it's worse than any other way you can try to do it.

are you saying that using the following instead of using eval
is preferable to using eval?
// evil() a candidate for "worse than eval"
function evil(code_to_eval){
var s = document.createElement("script");
s.type = "text/javascript";
s.innerHTML = code_to_eval;
document.body.appendChild(s);
}
and if so, why?

I don't know why the DOM approach could be better than eval, they will
result in the same thing, but eval is older... So, if I really wanted
to parse code, I'd use eval, since it's a built in function instead ;]

I'm curious to know where that guy will use the eval, because I never
needed to parse code...

Hmm, maybe a good use for the DOM approach would be to load script
files: "s.src = path", but this also could be done with "httprequest +
eval", with the advantange to know when the code gets fully loaded...

Marry Christmas for all, I had a really nice present yesterday hehe =]
--
Jonas Raoni Soares Silva
http://www.jsfromhell.com

[Randy Webb]

Jasen Betts said the following on 12/25/2005 3:49 AM:

On 2005-12-25, Randy Webb <Hi************@aol.com> wrote:

Jasen Betts said the following on 12/23/2005 1:43 AM:

On 2005-12-22, bj*****@hotmail.com <bj*****@hotmail.com> wrote:
Hi all,

I'm trying to generate client-side javascript with client-side
javascript. I'm doing this using innerHTML.
why not use eval?
Because it's worse than any other way you can try to do it.

are you saying that using the following instead of using eval
is preferable to using eval?

Yes, that is what I am saying. Whether you use eval or not is totally
dependend on what the code is, how you get it, and how much control you
have over it.

// evil() a candidate for "worse than eval"
//
function evil(code_to_eval){
var s = document.createElement("script");
s.type = "text/javascript";
s.innerHTML = code_to_eval;
document.body.appendChild(s);
}

and if so, why?

http://jibbering.com/faq/#FAQ4_40

But, using eval introduces un-needed overhead to the scripting engine.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Jasen Betts]

On 2005-12-25, Randy Webb <Hi************@aol.com> wrote:

Jasen Betts said the following on 12/25/2005 3:49 AM:

On 2005-12-25, Randy Webb <Hi************@aol.com> wrote:

Jasen Betts said the following on 12/23/2005 1:43 AM:

On 2005-12-22, bj*****@hotmail.com <bj*****@hotmail.com> wrote:
>Hi all,
>
>I'm trying to generate client-side javascript with client-side
>javascript. I'm doing this using innerHTML.
why not use eval?

Because it's worse than any other way you can try to do it.

are you saying that using the following instead of using eval
is preferable to using eval?

Yes, that is what I am saying. Whether you use eval or not is totally
dependend on what the code is, how you get it, and how much control you
have over it.

// evil() a candidate for "worse than eval"
//
function evil(code_to_eval){
var s = document.createElement("script");
s.type = "text/javascript";
s.innerHTML = code_to_eval;
document.body.appendChild(s);
}

and if so, why?

http://jibbering.com/faq/#FAQ4_40
it was for that reason that I reccomended eval.
But, using eval introduces un-needed overhead to the scripting engine.

and evil() doesn't?


--

Bye.
Jasen