changing text

im new to javascript but slowly getting better

what i want to do is have some text on the screen and when an event happens
for example click a button the text would change to what i want.

how would i do this ??

Hi Chris,

Here is some untested code. But it must be something like this.

<html>
<body>
<script language="JavaScript">
function changeText() {
var element = document.getElementById("myText");
element.innerHTML = "New Text";
}
</script>

<div id="myText">First text</div>
<input type="button" onclick="changeText()">
</body>
</html>

--

J.P.

chris schreef:[color=blue]
> im new to javascript but slowly getting better
>
> what i want to do is have some text on the screen and when an event happens
> for example click a button the text would change to what i want.
>
> how would i do this ??
>
>[/color]

yep that gives me something to work with - thanks

"J.P." <jp@provider.net> wrote in message
news:d5gjr4$kto$1@news4.zwoll1.ov.home.nl...[color=blue]
> Hi Chris,
>
> Here is some untested code. But it must be something like this.
>
> <html>
> <body>
> <script language="JavaScript">
> function changeText() {
> var element = document.getElementById("myText");
> element.innerHTML = "New Text";
> }
> </script>
>
> <div id="myText">First text</div>
> <input type="button" onclick="changeText()">
> </body>
> </html>
>
> --
>
> J.P.
>
> chris schreef:[color=green]
>> im new to javascript but slowly getting better
>>
>> what i want to do is have some text on the screen and when an event
>> happens for example click a button the text would change to what i want.
>>
>> how would i do this ??[/color][/color]

chris wrote:
[color=blue]
> im new to javascript but slowly getting better
>
> what i want to do is have some text on the screen and when an event happens
> for example click a button the text would change to what i want.
>
> how would i do this ??[/color]

You start by reading this groups FAQ, its URL is in my signature. You
are looking for DynWrite().

Then you drop the inappropriate alt.comp.lang.javascript from your memory.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly

J.P. wrote:[color=blue]
> Hi Chris,
>
> Here is some untested code. But it must be something like this.
>
> <html>
> <body>
> <script language="JavaScript">
> function changeText() {
> var element = document.getElementById("myText");
> element.innerHTML = "New Text";
> }
> </script>
>
> <div id="myText">First text</div>
> <input type="button" onclick="changeText()">
> </body>
> </html>
>
> --[/color]

Ok this code is internet explorer only,
if you want to do it the right way,
replace the content of the script element with the following code:

function changeText() {
var element=document.getElemenyById("myText");
var children=element.childNodes;
for(i=0;i<children.length;i++) {
element.removeChild(children.item(i));
}
element.appendChild(document.createTextNode("new Text"));
}

(note: the code is not tested)

See the DOM CORE ECMAScript bindings (ecmascript=javascript):
http://www.w3.org/TR/2000/REC-DOM-Le...t-binding.html
and the HTML DOM bindings:
http://www.w3.org/TR/2003/REC-DOM-Le...t-binding.html

Tjerk Wolterink wrote:[color=blue]
> J.P. wrote:[/color]
<snip>[color=blue][color=green]
>> function changeText() {
>> var element = document.getElementById("myText");
>> element.innerHTML = "New Text";
>> }[/color][/color]
<snip>[color=blue]
>
> Ok this code is internet explorer only,[/color]

So long as you don't count Mozilla/Netscape/Gecko, Konqueror/Safari,
IceBrowser, etc.
[color=blue]
> if you want to do it the right way,[/color]

Big claim, lets see.
[color=blue]
> replace the content of the script element
> with the following code:
>
> function changeText() {
> var element=document.getElemenyById("myText");[/color]

No feature testing to verify that the environment on this browser
supports a document.getElementById - method, or fallback emulation of
that method. That has the code erroring out on all pre-W3C DOM browsers
(so no hope of clean degredation).
[color=blue]
> var children=element.childNodes;[/color]

Operas 5 and 6 implement the - getElementById - method but do not
implement the - childNodes - collection so the lack of feature detection
results in them erroring out as soon as this undefined - children -
variable is used.
[color=blue]
> for(i=0;i<children.length;i++) {
> element.removeChild(children.item(i));
> }[/color]

Using a global variable as a loop counter is a very bad habit to get
into, and certainly should not be proposed as the "right way" of doing
anything.

The loop counter starts at zero, and so the zeroth item is removed form
the childNodes collection (where implemented. NetFront 4 errored out at
this point because is does not implement the - removeChild - method (not
being a dynamic W3C DOM browser)). With the first item in the collection
removed the second item drops down to first place (index zero), but the
loop counter is incremented, becoming 1. So the next iteration removes
the item form the childNodes collection at index 1, leaving the item now
at index zero in the collection. The item that was at index 2 drops down
to index 1 and the counter is incremented to two. The overall effect is
that this loop removes every other item from the childNodes collection.
[color=blue]
> element.appendChild(document.createTextNode("new Text"));
> }
>
> (note: the code is not tested)[/color]
<snip>

Apparently, though the fault in the node removal algorithm would
probably not have been apparent in superficial testing.

Richard.

Richard Cornford wrote:[color=blue]
> Tjerk Wolterink wrote:
>[color=green]
>>J.P. wrote:[/color]
>
> <snip>
>[color=green][color=darkred]
>>>function changeText() {
>>> var element = document.getElementById("myText");
>>> element.innerHTML = "New Text";
>>>}[/color][/color]
>
> <snip>
>[color=green]
>>Ok this code is internet explorer only,[/color]
>
>
> So long as you don't count Mozilla/Netscape/Gecko, Konqueror/Safari,
> IceBrowser, etc.[/color]

Do they support the innerHTML attribute?
[color=blue]
>
>[color=green]
>>if you want to do it the right way,[/color]
>
>
> Big claim, lets see.
>[/color]

the right way for me is to follow
the standards on w3c
[color=blue]
>[color=green]
>>replace the content of the script element
>>with the following code:
>>
>>function changeText() {
>>var element=document.getElemenyById("myText");[/color]
>
>
> No feature testing to verify that the environment on this browser
> supports a document.getElementById - method, or fallback emulation of
> that method. That has the code erroring out on all pre-W3C DOM browsers
> (so no hope of clean degredation).
>[/color]

ok but it should work on any browser that implemented the standard dom model.
[color=blue]
>[color=green]
>>var children=element.childNodes;[/color]
>
>
> Operas 5 and 6 implement the - getElementById - method but do not
> implement the - childNodes - collection so the lack of feature detection
> results in them erroring out as soon as this undefined - children -
> variable is used.
>
>[color=green]
>>for(i=0;i<children.length;i++) {
>>element.removeChild(children.item(i));
>>}[/color]
>
>
> Using a global variable as a loop counter is a very bad habit to get
> into, and certainly should not be proposed as the "right way" of doing
> anything.
>
> The loop counter starts at zero, and so the zeroth item is removed form
> the childNodes collection (where implemented. NetFront 4 errored out at
> this point because is does not implement the - removeChild - method (not
> being a dynamic W3C DOM browser)). With the first item in the collection
> removed the second item drops down to first place (index zero), but the
> loop counter is incremented, becoming 1. So the next iteration removes
> the item form the childNodes collection at index 1, leaving the item now
> at index zero in the collection. The item that was at index 2 drops down
> to index 1 and the counter is incremented to two. The overall effect is
> that this loop removes every other item from the childNodes collection.
>[/color]

ok, as i sad, the code was not tested.
[color=blue]
>[color=green]
>>element.appendChild(document.createTextNode("n ew Text"));
>>}
>>
>>(note: the code is not tested)[/color]
>
> <snip>
>
> Apparently, though the fault in the node removal algorithm would
> probably not have been apparent in superficial testing.
>
> Richard.
>[/color]

i think doing it the w3c way is better than to just try some code and
test it in different browsers.

Tjerk Wolterink wrote:[color=blue]
> Richard Cornford wrote:[color=green]
>> Tjerk Wolterink wrote:[color=darkred]
>>>J.P. wrote:[/color][/color][/color]
<snip>[color=blue][color=green][color=darkred]
>>>>function changeText() {
>>>> var element = document.getElementById("myText");
>>>> element.innerHTML = "New Text";
>>>>}[/color][/color][/color]
<snip>[color=blue][color=green][color=darkred]
>>>Ok this code is internet explorer only,[/color]
>>
>> So long as you don't count Mozilla/Netscape/Gecko,
>> Konqueror/Safari, IceBrowser, etc.[/color]
>
> Do they support the innerHTML attribute?[/color]

It's a property not an attribute, but yes they do support it, along with
others. While - innerHTML - may originally have been a Microsoft
proprietary property it is now widely supported in dynamic browsers,
indeed it is more widely supported than dynamic W3C DOM methods.
[color=blue][color=green][color=darkred]
>>>if you want to do it the right way,[/color]
>>
>> Big claim, lets see.[/color]
>
> the right way for me is to follow
> the standards on w3c[/color]

ECMA 262 is as important a standard in this context as the W3C DOM.
[color=blue][color=green][color=darkred]
>>>replace the content of the script element
>>>with the following code:
>>>
>>>function changeText() {
>>>var element=document.getElemenyById("myText");[/color]
>>
>> No feature testing to verify that the environment on this
>> browser supports a document.getElementById - method, or
>> fallback emulation of that method. That has the code
>> erroring out on all pre-W3C DOM browsers (so no hope of
>> clean degredation).[/color]
>
> ok but it should work on any browser that implemented the
> standard dom model.[/color]

And how many browsers fully implement the W3C standard model? The more
important fact is that that one line of code will work on any browser
that supports the W3C Core DOM - document.getelementById - method, which
is a fact that can be verified prior to any attempt to use the method.
The same is true of all other W3C DOM features, allowing a script to
verify its viability within any browser environment, and allowing issues
around the completeness of W3C DOM implementations to be side-stepped;
the browser only need support the features needed, rather than the full
standard, before a script can be successfully executed.

<snip>[color=blue][color=green][color=darkred]
>>>(note: the code is not tested)[/color]
>>
>> Apparently, though the fault in the node removal algorithm
>> would probably not have been apparent in superficial testing.[/color][/color]
<snip>[color=blue]
> i think doing it the w3c way is better than to just try some
> code and test it in different browsers.[/color]

And testing code in some browsers is better than not.

In banging on about W3C standards are you forgetting that client-side
scripting is an optional technology in user agents (by W3C standard), so
any and all scripts must fail in some environments? It is perfectly
reasonable that positive execution of scripts may only involve using the
W3C DOM specified features of host objects (if that was actually
achievable, which it isn't as no W3C standard includes - document - as a
property of the ECMAScript global object), but the design of such a
'standard' script should embrace the optional nature of client-side
scripting by providing for clean degradation. However, writing scripts
such that they error-out mid-execution in some environments will inhibit
their ability to take their designed path of clean degradation.

Richard.

Richard Cornford wrote:[color=blue]
> Tjerk Wolterink wrote:
>[color=green]
>>Richard Cornford wrote:
>>[color=darkred]
>>>Tjerk Wolterink wrote:
>>>
>>>>J.P. wrote:[/color][/color]
>
> <snip>
>[color=green][color=darkred]
>>>>>function changeText() {
>>>>> var element = document.getElementById("myText");
>>>>> element.innerHTML = "New Text";
>>>>>}[/color][/color]
>
> <snip>
>[color=green][color=darkred]
>>>>Ok this code is internet explorer only,
>>>
>>>So long as you don't count Mozilla/Netscape/Gecko,
>>>Konqueror/Safari, IceBrowser, etc.[/color]
>>
>>Do they support the innerHTML attribute?[/color]
>
>
> It's a property not an attribute, but yes they do support it, along with[/color]

It's an attribute, an attribute of an Element instance (in java).
Maybe they call it an propery in javascript, but i dont think so.

[color=blue]
> others. While - innerHTML - may originally have been a Microsoft
> proprietary property it is now widely supported in dynamic browsers,
> indeed it is more widely supported than dynamic W3C DOM methods.
>[/color]

Opera does not support the innerHTML attribute :-)
And i think in the future the w3c dom methods will be more supported.
[color=blue]
>
>[color=green][color=darkred]
>>>>if you want to do it the right way,
>>>
>>>Big claim, lets see.[/color]
>>
>>the right way for me is to follow
>>the standards on w3c[/color]
>
>
> ECMA 262 is as important a standard in this context as the W3C DOM.
>[/color]

The w3c standard is build upon the ecma-standard.
The ecma-standard is just a specification for the syntax & semantics of
the ecma-script language.

The dom is an Data-Structure that can be implemented in for example the
ecmascript language. The interface to access the dom is defined in the w3c
standard (for the Java langauge and the Ecmasscript language).
[color=blue]
>[color=green][color=darkred]
>>>>replace the content of the script element
>>>>with the following code:
>>>>
>>>>function changeText() {
>>>>var element=document.getElemenyById("myText");
>>>
>>>No feature testing to verify that the environment on this
>>>browser supports a document.getElementById - method, or
>>>fallback emulation of that method. That has the code
>>>erroring out on all pre-W3C DOM browsers (so no hope of
>>>clean degredation).[/color]
>>
>>ok but it should work on any browser that implemented the
>>standard dom model.[/color]
>
>
> And how many browsers fully implement the W3C standard model? The more
> important fact is that that one line of code will work on any browser
> that supports the W3C Core DOM - document.getelementById - method, which
> is a fact that can be verified prior to any attempt to use the method.
> The same is true of all other W3C DOM features, allowing a script to
> verify its viability within any browser environment, and allowing issues
> around the completeness of W3C DOM implementations to be side-stepped;
> the browser only need support the features needed, rather than the full
> standard, before a script can be successfully executed.
>
>[/color]

Its is dependend on the requirements of your script.
My requirements are (for example):
- future-proof code
- simple code (other programmers should be able to read and modify it)
- should work in the latest browsers

If you want your code to work in any browser you have to think
wether you want to use scripting after all.
[color=blue]
> <snip>
>[color=green][color=darkred]
>>>>(note: the code is not tested)
>>>
>>>Apparently, though the fault in the node removal algorithm
>>>would probably not have been apparent in superficial testing.[/color][/color]
>
> <snip>
>[color=green]
>>i think doing it the w3c way is better than to just try some
>>code and test it in different browsers.[/color]
>
>
> And testing code in some browsers is better than not.[/color]

ok i agree on that
[color=blue]
>
> In banging on about W3C standards are you forgetting that client-side
> scripting is an optional technology in user agents (by W3C standard), so
> any and all scripts must fail in some environments? It is perfectly
> reasonable that positive execution of scripts may only involve using the
> W3C DOM specified features of host objects (if that was actually
> achievable, which it isn't as no W3C standard includes - document - as a
> property of the ECMAScript global object)[/color]

mm yes you right, where is the global variable defined then?
Is there a standard for that?? Strange
[color=blue]
> , but the design of such a
> 'standard' script should embrace the optional nature of client-side
> scripting by providing for clean degradation. However, writing scripts
> such that they error-out mid-execution in some environments will inhibit
> their ability to take their designed path of clean degradation.
>[/color]

ok you should check wether the w3c dom is supported,
but i don't think using .innerHTML is a good choice.
But is i already sad: it all depends on the requirements.
[color=blue]
>
> Richard.
>
>[/color]

Tjerk Wolterink wrote:[color=blue]
> Richard Cornford wrote:[color=green]
>> Tjerk Wolterink wrote:[/color][/color]
<snip>[color=blue][color=green][color=darkred]
>>>Do they support the innerHTML attribute?[/color]
>>
>> It's a property not an attribute, but yes they do
>> support it, along with[/color]
>
> It's an attribute, an attribute of an Element
> instance (in java).[/color]

Java terminology does not necessarily apply to javascript.
[color=blue]
> Maybe they call it an propery in javascript,[/color]

They do.
[color=blue]
> but i dont think so.[/color]

You should try taking a look at some point.
[color=blue][color=green]
>> others. ...[/color][/color]
<snip>[color=blue]
> Opera does not support the innerHTML attribute :-)[/color]

Opera's HTML DOM has supported the innerHTML property from version 7 (it
is one of the others I mentioned).
[color=blue]
> And i think in the future the w3c dom methods will
> be more supported.[/color]

They might be (and particularly if XHTML ever becomes commercially
viable), but no new HTML scriptable dynamic browsers have been released
in the recent past without support for innerHTML.

<snip>[color=blue][color=green][color=darkred]
>>>the right way for me is to follow
>>>the standards on w3c[/color]
>>
>> ECMA 262 is as important a standard in this context
>> as the W3C DOM.[/color]
>
> The w3c standard is build upon the ecma-standard.[/color]

The W3C DOM standards have been written to be language-neutral, with the
main interface specifications defined in IDL for just that reason.
[color=blue]
> The ecma-standard is just a specification for the syntax
> & semantics of the ecma-script language.[/color]

And includes the definition of variable scopeing in the language. Which
was hardly well employed in your example code.

<snip>[color=blue]
> Its is dependend on the requirements of your script.
> My requirements are (for example):
> - future-proof code[/color]

Code that will work in the future does not have to be code that code
that errors-out today. indeed, code that can cope with the current
spectrum of scriptable browsers without erroring is more likely to still
be working as designed in a theoretically more standardised future.
[color=blue]
> - simple code (other programmers should be able to read
> and modify it)
> - should work in the latest browsers[/color]

As opposed to code that does work in the latest browsers?
[color=blue]
> If you want your code to work in any browser you have
> to think wether you want to use scripting after all.[/color]

Surly no using scripting is the best way of guaranteeing that your
script will not work in any browsers?

<snip>[color=blue][color=green]
>> is perfectly reasonable that positive execution of scripts
>> may only involve using the W3C DOM specified features of
>> host objects (if that was actually achievable, which it
>> isn't as no W3C standard includes - document - as a
>> property of the ECMAScript global object)[/color]
>
> mm yes you right, where is the global variable defined
> then? Is there a standard for that?? Strange[/color]

Global variable? The global object is defined in ECMA 262, as part of
the language specification.

<snip>[color=blue]
> ok you should check wether the w3c dom is supported,
> but i don't think using .innerHTML is a good choice.[/color]

Did I say it was a good idea? I just corrected the assertion that
innerHTML was IE only, as it is actually very widely supported. However,
there are reasons for preferring innerHTML. It is certainly the most
obvious approach for inserting HTML fragments into a document if they
take the form of strings of mark-up. It is also a very simple mechanism
that is easy to understand for less experienced javascript programmers.
Personally I am more or a fan of structural simplicity in code
architecture than of the use of simple code in object implementations,
but others prefer to see simplicity at the lowest possible level.
[color=blue]
> But is i already sad: it all depends on the requirements.[/color]

My requirements, though never formally expressed in specifications,
include not being responsible for a user seeing a javascript error
report. It may just be a matter of taking pride in what I do, but I
think that users are justified in believing that a script author that
puts up an error report is incompetent.

Richard.

Richard Cornford wrote:[color=blue]
> Tjerk Wolterink wrote:
>[color=green]
>>Richard Cornford wrote:
>>[color=darkred]
>>>Tjerk Wolterink wrote:[/color][/color]
>
> <snip>
>[color=green][color=darkred]
>>>>Do they support the innerHTML attribute?
>>>
>>>It's a property not an attribute, but yes they do
>>>support it, along with[/color]
>>
>>It's an attribute, an attribute of an Element
>>instance (in java).[/color]
>
>
> Java terminology does not necessarily apply to javascript.
>
>[color=green]
>>Maybe they call it an propery in javascript,[/color]
>
>
> They do.
>[/color]

they do?
[color=blue]
>[color=green]
>>but i dont think so.[/color]
>
>
> You should try taking a look at some point.[/color]

well thanks for the info.
im a diehard java programmer, so id like to call it an attribute :-)
[color=blue]
>
>[color=green][color=darkred]
>>>others. ...[/color][/color]
>
> <snip>
>[color=green]
>>Opera does not support the innerHTML attribute :-)[/color]
>
>
> Opera's HTML DOM has supported the innerHTML property from version 7 (it
> is one of the others I mentioned).
>
>[color=green]
>>And i think in the future the w3c dom methods will
>>be more supported.[/color]
>
>
> They might be (and particularly if XHTML ever becomes commercially
> viable), but no new HTML scriptable dynamic browsers have been released
> in the recent past without support for innerHTML.
>[/color]

i do not know for sure, but i think those browser do implement also
part of the dom.
[color=blue]
> <snip>
>[color=green][color=darkred]
>>>>the right way for me is to follow
>>>>the standards on w3c
>>>
>>>ECMA 262 is as important a standard in this context
>>>as the W3C DOM.[/color]
>>
>>The w3c standard is build upon the ecma-standard.[/color]
>
>
> The W3C DOM standards have been written to be language-neutral, with the
> main interface specifications defined in IDL for just that reason.
>
>[color=green]
>>The ecma-standard is just a specification for the syntax
>>& semantics of the ecma-script language.[/color]
>
>
> And includes the definition of variable scopeing in the language. Which
> was hardly well employed in your example code.[/color]

What was wrong with it then?
[color=blue]
>
> <snip>
>[color=green]
>>Its is dependend on the requirements of your script.
>>My requirements are (for example):
>>- future-proof code[/color]
>
>
> Code that will work in the future does not have to be code that code
> that errors-out today. indeed, code that can cope with the current
> spectrum of scriptable browsers without erroring is more likely to still
> be working as designed in a theoretically more standardised future.
>
>[color=green]
>>- simple code (other programmers should be able to read
>> and modify it)
>>- should work in the latest browsers[/color]
>
>
> As opposed to code that does work in the latest browsers?
>
>[color=green]
>>If you want your code to work in any browser you have
>>to think wether you want to use scripting after all.[/color]
>
>
> Surly no using scripting is the best way of guaranteeing that your
> script will not work in any browsers?
>[/color]

I meant, if a requirement is near 100% operability you
should not go into scripting.
[color=blue]
>[color=green][color=darkred]
>>>is perfectly reasonable that positive execution of scripts
>>>may only involve using the W3C DOM specified features of
>>>host objects (if that was actually achievable, which it
>>>isn't as no W3C standard includes - document - as a
>>>property of the ECMAScript global object)[/color]
>>
>>mm yes you right, where is the global variable defined
>>then? Is there a standard for that?? Strange[/color]
>
>
> Global variable? The global object is defined in ECMA 262, as part of
> the language specification.[/color]

i meant, the global document variable that is used so often in
javascripts. where is that defined? Are there standards for that?
Or is every browser just using there own standards?
[color=blue]
>
> <snip>
>[color=green]
>>ok you should check wether the w3c dom is supported,
>>but i don't think using .innerHTML is a good choice.[/color]
>
>
> Did I say it was a good idea? I just corrected the assertion that
> innerHTML was IE only, as it is actually very widely supported. However,
> there are reasons for preferring innerHTML. It is certainly the most
> obvious approach for inserting HTML fragments into a document if they
> take the form of strings of mark-up. It is also a very simple mechanism
> that is easy to understand for less experienced javascript programmers.
> Personally I am more or a fan of structural simplicity in code
> architecture than of the use of simple code in object implementations,
> but others prefer to see simplicity at the lowest possible level.
>
>[color=green]
>>But is i already sad: it all depends on the requirements.[/color]
>
>
> My requirements, though never formally expressed in specifications,
> include not being responsible for a user seeing a javascript error
> report. It may just be a matter of taking pride in what I do, but I
> think that users are justified in believing that a script author that
> puts up an error report is incompetent.
>[/color]

Yes ok, but most javascripts are not (for me) hard requirements for
the webapplication to function (and i think javascript should never be used
for important requirements of your webapp).
So i try to check wether the browser supports the w3c, if it doesnt
support it an error message will display.
[color=blue]
> Richard.
>[/color]

In the past i too wanted to create code that could run in any browser.
But that is just not-to-do. Because it will cost you uge amount of time.
Therefore i choosed this path, and its rather safe because most
browsers implement the most used parts of the dom.

Tjerk Wolterink wrote:[color=blue]
> Richard Cornford wrote:[color=green]
>> Tjerk Wolterink wrote:[/color][/color]
<snip>[color=blue][color=green][color=darkred]
>>>Maybe they call it an propery in javascript,[/color]
>>
>> They do.[/color]
>
> they do?[/color]

Yes they do.

<snip>[color=blue]
> well thanks for the info.
> im a diehard java programmer, so id like
> to call it an attribute :-)[/color]

In the context of browser scripting there are things that are
unambiguously attributes; HTML attributes and their DOM representations.
Inappropriately applying terminology is likely to result in the blurring
of concepts that should be distinct, and result in misconceptions and
confusion.

<snip>[color=blue][color=green][color=darkred]
>>>And i think in the future the w3c dom methods will
>>>be more supported.[/color]
>>
>>
>> They might be (and particularly if XHTML ever becomes
>> commercially viable), but no new HTML scriptable
>> dynamic browsers have been released in the recent
>> past without support for innerHTML.
>>[/color]
>
> i do not know for sure, but i think those browser do
> implement also part of the dom.[/color]

The W3C DOM standards are being adopted and implemented, other features
are also implemented, mostly for compatibility with existing browser.

<snip>[color=blue][color=green][color=darkred]
>>> The ecma-standard is just a specification for the
>>> syntax & semantics of the ecma-script language.[/color]
>>
>>
>> And includes the definition of variable scopeing in
>> the language. Which was hardly well employed in your
>> example code.[/color]
>
> What was wrong with it then?[/color]

The general programming axiom that variables should never be given more
scope than they absolutely need holds as much for javascript as it does
in any other language. Your code used a global variable as a loop
counter, which is a particularly dangerous habit to get into because it
is likely to be repeated in functions that are used recursively, with
erroneous results that are rarely obvious.

<snip>[color=blue][color=green][color=darkred]
>>>If you want your code to work in any browser you have
>>>to think wether you want to use scripting after all.[/color]
>>
>> Surly no using scripting is the best way of guaranteeing
>> that your script will not work in any browsers?
>>[/color]
>
> I meant, if a requirement is near 100% operability you
> should not go into scripting.[/color]

No, that is where the concept of clean degradation by design comes in.
If a web page is completely operable without scripting it can be
significantly enhanced through the use of scripting, to the advantage of
users who have browsers/configurations that allow it, and still fully
functional for everyone else. The reason for verifying that the
environment fully supports the features required by the script prior to
using them is so that whenever the environment cannot facilitate the
script it can degrade under its own control back to the underlying (and
fully operable) HTML, rather than erroring mid-execution and potentially
leaving the user experiencing an otherwise usable page crippled by the
failure of a faulty script.

So long as it is not directly harmful there is no reason for not
attempting to get as much out of a user's browser as it is capable of
giving.

<snip>[color=blue][color=green]
>> Global variable? The global object is defined in ECMA
>> 262, as part of the language specification.[/color]
>
> i meant, the global document variable that is used so
> often in javascripts. where is that defined? Are there
> standards for that?[/color]

The global document property is not part of any formal
specification/standard/recommendation.

As almost no DOM script can be written without referring to the global -
document - property, and that property is not DOM standard itself, it is
almost not possible to write an exclusively DOM standard script. Making
a nonsense of any call to abandon non-standardised features in favour of
the DOM standard; once abandoned the DOM standard is barley useable.
[color=blue]
> Or is every browser just using there own standards?[/color]

What browsers have always done is attempt to copy the more commonly used
features of existing browsers, because they mostly want their new
browsers to appear to work with existing scripts.

<snip>[color=blue]
> Yes ok, but most javascripts are not (for me) hard
> requirements for the webapplication to function (and
> i think javascript should never be used for important
> requirements of your webapp).[/color]

It depends on the context. For a public web site a dependency on
client-side scripting is a bad idea, but scripted enhancements that
degrade cleanly can be appreciated by some users, without doing any harm
to the rest.

A web application can be a more specific situation. If the application
is intended for general public use then the same applies as applies to
public web sites. But a web application can also exist to allow specific
users (say the employees of a company) to perform tasks remotely, using
the Internet only as a means of client-server communication. In that
case the users may be motivated to use a browser with which the
application is known to function, and configure that browser in
accordance with appropriate instructions (such as placing the server's
URL in a lower security, or less restricted, zone than they would
normally browse with). In that case a dependency on client side
scripting may be completely acceptable. And on an Intranet that may be
even more true.
[color=blue]
> So i try to check wether the browser supports the
> w3c, if it doesnt support it an error message will
> display.[/color]

In a public Internet context there is little point showing error
messages to users. Even if they understand what is being said they will
probably be incapable of, or unwilling to, do anything about it. It is
better to design for clean degradation, so the site broadly works
anyway, and just provides a better experience when the user's browser
facilitates the scripts (be those facilities W3C DOM specified or
otherwise).
[color=blue]
> In the past i too wanted to create code that could
> run in any browser. But that is just not-to-do.
> Because it will cost you uge amount of time.[/color]

Running a script on any browser is impossible, all scripts will fail to
fully execute as designed in at lest some browsers. But that does not
mean you cannot create a web page (or a web application, server-side)
that will not fully operate in all HTML browsers, and then significantly
enhance it with cleanly degrading scripts. Thus achieving 100% coverage
with just two script execution paths (fully executed or cleanly
degrading). Maximum results with minimum efforts. Leaving the only
effort issue deciding how much work to put into expanding the set of
browsers on which the script is fully functional.
[color=blue]
> Therefore i choosed this path, and its rather safe
> because most browsers implement the most used parts of the dom.[/color]

Using a sub-set of the DOM that could be described as 'most used' is
placing an arbitrary restriction on what can be achieved. There is no
reason not to be using everything and anything that a browser is capable
of facilitating, if that facility is verified as being available prior
to its use, and a path of clean degradation is available otherwise.

Richard.

Richard Cornford wrote:[color=blue]
> Tjerk Wolterink wrote:
>
> [snip]
>[color=green][color=darkred]
>>>>The ecma-standard is just a specification for the
>>>>syntax & semantics of the ecma-script language.
>>>
>>>
>>>And includes the definition of variable scopeing in
>>>the language. Which was hardly well employed in your
>>>example code.[/color]
>>
>>What was wrong with it then?[/color]
>
>
> The general programming axiom that variables should never be given more
> scope than they absolutely need holds as much for javascript as it does
> in any other language. Your code used a global variable as a loop
> counter, which is a particularly dangerous habit to get into because it
> is likely to be repeated in functions that are used recursively, with
> erroneous results that are rarely obvious.
>[/color]

did i do that?

the code:

function changeText() {
var element=document.getElemenyById("myText");
var children=element.childNodes;
for(i=0;i<children.length;i++) {
element.removeChild(children.item(i));
}
element.appendChild(document.createTextNode("new Text"));
}

is see nothing wrong with it. i is in the scope of changetext,
ok i should have put a var before it like this:

for(var i=0;i<children.length;i++) {
element.removeChild(children.item(i));
}

but that doesnt change the meaning of the loop.

I agree on the other comments you made about scripting.

Tjerk Wolterink wrote:

[snip]
[color=blue]
> function changeText() {
> [...]
> for(i=0;i<children.length;i++) {
> [...]
> }
>
> [...] i is in the scope of changetext,[/color]

No, it isn't. Do you think Richard would have raised the issue if it was?

The use of a var statement creates a variable in appropriate scope - either
the global object or the variable object of a function - depending on where
the statement appears. As no such statement exists, the i variable will be
created as a property of the former.

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

Tjerk Wolterink wrote:[color=blue]
> Richard Cornford wrote:
>[color=green]
>> Tjerk Wolterink wrote:
>>
>> [snip]
>>[color=darkred]
>>>>> The ecma-standard is just a specification for the
>>>>> syntax & semantics of the ecma-script language.
>>>>
>>>>
>>>>
>>>> And includes the definition of variable scopeing in
>>>> the language. Which was hardly well employed in your
>>>> example code.
>>>
>>>
>>> What was wrong with it then?[/color]
>>
>>
>>
>> The general programming axiom that variables should never be given more
>> scope than they absolutely need holds as much for javascript as it does
>> in any other language. Your code used a global variable as a loop
>> counter, which is a particularly dangerous habit to get into because it
>> is likely to be repeated in functions that are used recursively, with
>> erroneous results that are rarely obvious.
>>[/color]
>
> did i do that?
>
> the code:
>
> function changeText() {
> var element=document.getElemenyById("myText");
> var children=element.childNodes;
> for(i=0;i<children.length;i++) {
> element.removeChild(children.item(i));
> }
> element.appendChild(document.createTextNode("new Text"));
> }
>
>
> is see nothing wrong with it. i is in the scope of changetext,[/color]

No, i is in the scope of the document.
[color=blue]
> ok i should have put a var before it like this:
>
> for(var i=0;i<children.length;i++) {
> element.removeChild(children.item(i));
> }
>
> but that doesnt change the meaning of the loop.[/color]

but it changes the scope of i. Try this test:

var i=0;

function function1(){
for (var i=0;i<100;i++){}
}

function function2(){
alert(i)
}

<button onclick="function1()">Function 1</button>
<button onclick="function2()">Function 2</button>

Load the page, click Function 2 Button, then Function 1 Button, then the
Function 2 Button. Then, remove the var declaration and rerun the test.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly

Tjerk Wolterink wrote:[color=blue]
> Richard Cornford wrote:[/color]
<snip>[color=blue][color=green]
>> ... . Your code used a global variable as a
>> loop counter, ...[/color][/color]
<snip>[color=blue]
> did i do that?
>
> the code:
>
> function changeText() {
> var element=document.getElemenyById("myText");
> var children=element.childNodes;
> for(i=0;i<children.length;i++) {
> element.removeChild(children.item(i));
> }
> element.appendChild(document.createTextNode("new Text"));
> }
>
> is see nothing wrong with it. i is in the scope
> of changetext,[/color]

That depends a lot on how you think about the scope of - changetext -.
At the point of first executing - changetext - there are no object in
the system with a property named "i". The function object that is
referred to by the property of the global object with the name
'changetext' has an internal [[Scope]] property that points to the scope
chain in which it was created. That function object was created in the
global scope so that internal [[Scope]] property points to a scope chain
containing only the global object.

When - changetext - is executed its execution context has a scope chain
consisting of a Variable/Activation object followed by the objects in
the scope chain referred to by the function object's internal [[Scope]]
property. So that is a scope chain that is two objects deep, the
Activation/Variable object followed by the global object.

The execution context's Variable/Activation object has named properties
for each formal parameter, inner function declaration and each function
local variable (as declared with the - var - keyword) within the
function. In this case -changetext - has no formal parameters and no
inner function declarations so the Variable/Activation object has three
named properties. One for each of the declared function local
variables; - element - and - children -, and one for the - arguments -
object that is created for each execution context.

The identifier - i - is resolved against the execution context's scope
chain (as per ECMA 262 3rd edition; Section 10.1.4), but the first time
it is referred to (as -> i = 0) there is no object on that scope chain
with a property named "i" so the result is a Reference type with a null
base object and the property name "i". An assignment to such a Reference
substitutes the global object for the null base object (ECMA262 3rd
edition; Section 8.7.2) and as the global object has no property named
"i", such a property is created and the value (zero) assigned to it.

And so - i - is created as a global variable by the act of assigning a
value to an identifier that cannot be resolved against the scope chain.
All subsequent references to - i - are resolved as a reference to that
property of the global object.
[color=blue]
> ok i should have put a var before it like this:
>
> for(var i=0;i<children.length;i++) {
> element.removeChild(children.item(i));
> }[/color]

Yes you should. Using the - var - keyword would result in a proerty of
the execution context's Varaible/Activation object being created wit the
name "i" and so the identifier - i - would resolve as a referrence to
the "i" proeprty of that object, which only appears on the scope chain
of the current exectuion context and the [[Scope]] proeprties of
fucntion objects created within that execution context (or nested within
the execution contexts of those inner fucntions). I.E. With - var - it
is a fucntion local variable, and without it - i - becomes a global
varaible.

Javascript's lexical scopeing may not be as fine-grained as Java's block
scopeing but that is no reason disregard the scope of variables. Indeed,
the language's native support for closures makes understanding variable
scope potentially very valuable and exploitable.
[color=blue]
> but that doesnt change the meaning of the loop.[/color]
<snip>

The meaning of things was never the issue with global variables, it is
the interactions between things that are effected by the scope of the
variables they reference.

Richard.

Tjerk Wolterink schrieb:
[color=blue]
> Richard Cornford wrote:[color=green][color=darkred]
> >> Do they support the innerHTML attribute?[/color]
> >
> > It's a property not an attribute, but yes they do support it,
> > along with[/color]
>
> It's an attribute, an attribute of an Element instance (in java).[/color]

Actually, in Java it would be a field of an HTMLElement instance:
see e.g. http://java.sun.com/j2se/1.5.0/docs/...et/Applet.html
[color=blue]
> Maybe they call it an propery in javascript,[/color]

They do call it a _property_ of an HTMLElement object (i.e. an object
implementing the HTMLElement interface or having HTMLElement as its
constructor) in JavaScript 1.0 and all ECMAScript implementations,
including Netscape JavaScript 1.1+ and Micro$oft JScript.

PointedEars

changing text

re: changing text

re: changing text

re: changing text

re: changing text

re: changing text

re: changing text

re: changing text

re: changing text

re: changing text

re: changing text

re: changing text

re: changing text

re: changing text

re: changing text

re: changing text

re: changing text

Similar JavaScript / Ajax / DHTML bytes

/bytes/development

/bytes/it

/bytes/about