Dear All,
Hopefully I have a simple problem. Basically, I just want to alter some text
with JS.
Here is some of my test code:
<snip>
<script type="text/javascript">
var tmp='a';
function myfunction(){
tmp='b';
}
</script>
<input type="button" onClick=javascript:myfunction() >
<script type="text/javascript">
document.write(tmp);
</script>
<snip>
So when variable tmp is updated, I want to change the 'document.write(tmp)'
to reflect this.
If there is a better of changing text, feel free to suggest it.
Many thanks
Colin
27  2147 
In article <cj**********@ucsnew1.ncl.ac.uk>,
"C Gillespie" <cs******@hotmail.com> wrote: Hopefully I have a simple problem. Basically, I just want to alter some text
with JS.
Here is some of my test code:
<input type="button" onClick=javascript:myfunction() >
<script type="text/javascript">
document.write(tmp);
</script>
<snip>
1) The document.write may only be used when the document is first
loaded.
2) There is no need for javascript : in an event handler. Javascript is
assumed in all event handler such as onclick.
3) It is best to put quotes around the javascript code in an event
handler. onClick="myfunction();"
4) It is best to put in the trailing semi-colon ";".
You need to access the document node structure to insert the text. Here
is an example of this, Robert:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>insert some text</title>
<script type="text/javascript">
function changeText(label,text)
{
var node;
if (document.getElementById)
{
var node = document.getElementById(label);
if (node)
{
/*See if we already inserted a node. */
var nextNode = node.firstChild;
if(nextNode)
{
/* Yes, replace the text. */
nextNode.data = text.value;
}
else
{
/* No, Insert the new node. */
node.appendChild(
document.createTextNode(text.value));
node.text = text;
}
}
else
{
alert("You need to create a span tag with " +
"the id of " + label + ".");
return;
}
}
else
{
alert(" document.getElementByID failed. " +
"You need to use a newer browser.");
return;
}
}
</script>
</head>
<body>
<p>Insert or change some text.
<br>
Don't forget to see what happens when you
press the button more than once.</p>
<form id="myForm">
<input type="text" name="total" size="20">
<br><br>
<input type="button"
name="activate"
value="change the text"
onclick="changeText('insert',
document.forms['myForm'].elements['total']);">
<br>
</form>
<p>Change this "
<span id='insert'>
</span>".</p>
</body>
</html>
I tried too but in a different manner...
Hope it helps:
<form>
<input type="text" name="myText" value="a">
<input type="button" name="myButton" onClick="return
myfunction(this.form);">
</form>
<script language="JavaScript1.2" type="text/javascript">
function myfunction(frm)
{
frm.myText.value = "b";
}
</script>
If you don't want the "a" to be in a text field, but just a text I
don't konw how to do it...
S.
JRS: In article <rc*****************************@news1.west.earthl ink.n
et>, dated Fri, 24 Sep 2004 17:58:55, seen in news:comp.lang.javascript,
Robert <rc*******@my-deja.com> posted :
You need to access the document node structure to insert the text. Here
is an example of this, Robert:
That way will, I think, not work in as many browsers as the method in
our FAQ, 4.15.
There is no need to require getElementById ; see past posts here, and my
page js-other.htm , for generating it, briefly.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
In article <vw**************@merlyn.demon.co.uk>,
Dr John Stockton <sp**@merlyn.demon.co.uk> wrote: That way will, I think, not work in as many browsers as the method in
our FAQ, 4.15.
I do not follow ever detail about the code in this section, but it seems
to use innerHTML which I understand isn't in W3C.
There is no need to require getElementById ; see past posts here, and my
page js-other.htm , for generating it, briefly.
I added the code to support documnent.all and did some general fix up.
I tested this code on safari 1.0, Netscape 7.2, and IE 5.2 on MacOS
10.2.6. I test on Windows 95 with IE 4.72 to invoke the document.all
code.
I consider this more of a proof of concept than a final code. It would
require more testing to verify that it worked with the browsers one
wanted to support.
Robert
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>insert some text</title>
<script type="text/javascript">
function changeText(label,text)
{
var node;
if (document.getElementById)
{
var node = document.getElementById(label);
if (node)
{
/*See if we already inserted a node. */
var nextNode = node.firstChild;
if(nextNode)
{
/* Yes, replace the text. */
nextNode.data = text.value;
}
else
{
/* No, Insert the new node. */
node.appendChild(
document.createTextNode(text.value));
}
}
else
{
alert("You need to create a span tag with " +
"the id of " + label + ".");
return;
}
}
else
{
if (document.all)
{
document.all[label].innerHTML = text.value;
}
else
{
alert("Constructs document.getElementByID " +
"and document.all failed. " +
"You need to use a newer browser.");
return;
}
}
}
</script>
</head>
<body>
<p>Insert or change some text.
<br>
Don't forget to see what happens when you
press the button more than once.</p>
<form name="myForm">
<input type="text" name="total" size="20">
<br><br>
<input type="button"
name="activate"
value="change the text"
onclick="changeText('insert',
document.forms['myForm'].elements['total']);">
<br>
</form>
<p>Change this "<span id='insert'>
</span>".</p>
</body>
</html>
On Sat, 25 Sep 2004 04:33:17 GMT, Robert <rc*******@my-deja.com> wrote: In article <vw**************@merlyn.demon.co.uk>,
Dr John Stockton <sp**@merlyn.demon.co.uk> wrote:
That way will, I think, not work in as many browsers as the method in
our FAQ, 4.15.
I do not follow ever detail about the code in this section, but it seems
to use innerHTML which I understand isn't in W3C.
It's not, but a lot of browsers do support it. There is no need to require getElementById ; see past posts here, and
my page js-other.htm , for generating it, briefly.
I added the code to support documnent.all and did some general fix up.
Note: I'm not correcting you, just suggesting a different approach.
Here's the code I use for gEBI and d.all support (part of a larger
collection of code):
var domCore = (function() {
function isN(o) {return 'number' == typeof o;}
return ({
getElementById : document.getElementById ?
function(n) {return document.getElementById(n);}
: document.all ?
function(n) {
var e = document.all[n], i = e.length;
if(isN(i)) {while(i--) {if(e[i].id == n) return e[i];}}
else if(e.id == n) {return e;}
return null;
}
: function() {return null;}
});
})();
It tries to ensure that only one element is returned by the all
collection, and that that element was retrieved by its id, only.
You could then test whether innerHTML was supported with a typeof test:
var node = domCore.getElementById(label);
if(node) {
var child;
if('string' == typeof node.innerHTML) {
node.innerHTML = text.value;
} else if((child = node.firstChild)) {
child.data = text.value;
} else if(document.createTextNode && node.appendChild) {
node.appendChild(document.createTextNode(text.valu e));
}
}
Probably a better way than that, though.
[snip]
Mike
--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message news:<opsevovyvzx13kvk@atlantis>... On Sat, 25 Sep 2004 04:33:17 GMT, Robert <rc*******@my-deja.com> wrote:
In article <vw**************@merlyn.demon.co.uk>,
Dr John Stockton <sp**@merlyn.demon.co.uk> wrote:
Note: I'm not correcting you, just suggesting a different approach.
Here's the code I use for gEBI and d.all support (part of a larger
collection of code):
var domCore = (function() {
function isN(o) {return 'number' == typeof o;}
return ({
getElementById : document.getElementById ?
function(n) {return document.getElementById(n);}
: document.all ?
function(n) {
var e = document.all[n], i = e.length;
if(isN(i)) {while(i--) {if(e[i].id == n) return e[i];}}
else if(e.id == n) {return e;}
return null;
}
: function() {return null;}
});
})();
It tries to ensure that only one element is returned by the all
collection, and that that element was retrieved by its id, only.
This will take some study. I realize that this is copied code. Any
advantages of nesting the code in the return statement. You did end
up rather deep in all of these )}.
You could then test whether innerHTML was supported with a typeof test:
var node = domCore.getElementById(label);
if(node) {
var child;
if('string' == typeof node.innerHTML) {
node.innerHTML = text.value;
} else if((child = node.firstChild)) {
child.data = text.value;
} else if(document.createTextNode && node.appendChild) {
node.appendChild(document.createTextNode(text.valu e));
}
}
Dr John Stockton wants to add a code path that doesn't require the use
of getElementById().
While I didn't think of useing innerHTML for this, I'd think that
using innerHTML would be slower than inserting the node directly.
I thought that side effects are questionable. I see an if statement
as a structure to test something so I do not expect things to change
inside of the if statement.
Robert
Robert wrote: Michael Winter wrote:
<snip> Note: I'm not correcting you, just suggesting a different
approach.
Here's the code I use for gEBI and d.all support (part of
a larger collection of code):
var domCore = (function() {
function isN(o) {return 'number' == typeof o;}
return ({
getElementById : document.getElementById ?
function(n) {return document.getElementById(n);}
: document.all ?
function(n) {
var e = document.all[n], i = e.length;
^
Isn't it a bit premature to be assuming that the - document.all -
collection has returned something at this point? Any undefined (or null)
value will error at the reading of - e.length -. I suppose you could
assign a value to e with a logical OR expression where undefined or null
would result in a right hand side value that could be type converted
for - e.length - and - e.id -, returning undefined at that point. A
number or boolean literal should be practical as their object
representations lack both properties (which is not true of a string):-
var e = (document.all[id] || false);
- or:-
var e = (document.all[id] || 0);
- or an explicit object that has no - length - or - id - property:-
var e = (document.all[id] || {} );
if(isN(i)) {while(i--) {if(e[i].id == n) return e[i];}}
else if(e.id == n) {return e;}
return null;
}
: function() {return null;}
});
})();
It tries to ensure that only one element is returned by
the all collection, and that that element was retrieved
by its id, only.
This will take some study. I realize that this is copied
code. Any advantages of nesting the code in the return
statement.
Function expressions do not result in the creation of a corresponding
function object until they are evaluated. So while it would be possible
to define all of the possible assigned functions with inner function
declarations their appearance as expressions in the conditional
statement means that only the one function expression evaluated will
result in the creation of a function object (which is faster in
execution than creating 3 as would happen with separate inner function
declarations).
You did end up rather deep in all of these )}.
The resulting code looks convoluted but once you are used to seeing
function expressions, and assuming the code is indented to express
structure and parenthesised to highlight the precedence in expression
evaluation, it is not nearly as complex as it might at first appear.
Personally I might have been inclined to put a few more parentheses in.
Around the conditional expression and maybe its contained function
expressions. But you can go overboard with parentheses, and javascript
authors should be capable of recognising where an expression is implied
by its context in most situations anyway.
You could then test whether innerHTML was supported with
a typeof test:
While a - typepf - test will indicate the existence of an innerHTML
property (of string type), it has been suggested that innerHTML might be
available as a read-only property on some less-dynamic browsers (I don't
recall whether specific examples have ever been cited). Hence the more
elaborate strategy in the notes for #4.15.
var node = domCore.getElementById(label);
if(node) {
var child;
if('string' == typeof node.innerHTML) {
node.innerHTML = text.value;
} else if((child = node.firstChild)) {
child.data = text.value;
} else if(document.createTextNode && node.appendChild) {
node.appendChild(document.createTextNode(text.valu e));
}
}
Dr John Stockton wants to add a code path that doesn't require
the use of getElementById().
But this code calls - domCore.getElementById -, a method of the object
set-up in the first example block of code. And that doesn't require -
document.getElementById -.
While I didn't think of useing innerHTML for this, I'd
think that using innerHTML would be slower than inserting
the node directly.
Using innerHTML makes most sense when attempting to change more than
just the text of one text Node (i.e. To insert a branch of a DOM tree,
especially when that branch is defined a string of HTML source code).
I thought that side effects are questionable. I see an
if statement as a structure to test something so I do
not expect things to change inside of the if statement.
Moving the assignment expression outside of the - if - statement means
having a second - if/else - inside the - else - clause of a first.
Whatever might be gained in attempting to clarify that one - if -
statement can be weighed against losing the clear one-of-three structure
in the containing code. Parenthesising the assignment expression within
the - if - expression should make it clear that the assignment precedes
the evaluation of the - if - expression, which is based on the result of
the assignment expression.
Richard.
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message news:<2r*************@uni-berlin.de>...
You could then test whether innerHTML was supported with a typeof test:
var node = domCore.getElementById(label);
if(node) {
var child;
if('string' == typeof node.innerHTML) {
node.innerHTML = text.value;
} else if((child = node.firstChild)) {
child.data = text.value;
} else if(document.createTextNode && node.appendChild) {
node.appendChild(document.createTextNode(text.valu e));
}
}
I thought that side effects are questionable. I see an
if statement as a structure to test something so I do
not expect things to change inside of the if statement.
Moving the assignment expression outside of the - if - statement means
having a second - if/else - inside the - else - clause of a first.
Whatever might be gained in attempting to clarify that one - if -
statement can be weighed against losing the clear one-of-three structure
You have to mentally insert the assignment statement and realize that
it isn't a conditional thing. My thought process is that I have to
push the if statement down in my thinking. Remember the assignment.
Then, I have to recall the if statement. You can see from my
formatting of the code. That I do not have to do this mental activity
because it is written on paper.
At least for me, I have to do the translation in my head. It is more
complicated for me to understand.
in the containing code. Parenthesising the assignment expression within
the - if - expression should make it clear that the assignment precedes
the evaluation of the - if - expression, which is based on the result of
the assignment expression.
I reformulated the logic here.
var node = domCore.getElementById(label);
if(node)
{
var child;
if('string' == typeof node.innerHTML)
{
node.innerHTML = text.value;
}
else
{
child = node.firstChild;
if(child)
{
child.data = text.value;
}
else if(document.createTextNode &&
node.appendChild)
{
node.appendChild(
document.createTextNode(text.value));
}
}
}
Shows clearly:
1) What goes with what
2) code parrallels the oder the machine will run the code. You do not
have to back scan in the if statment nor do mental push and pop
operations.
3) avoids the confusion over = and ==
4) Hilights the assignment statement because is valid for the rest of
the code block. It is valid outside the rest of the if statement. I
believe this reason alone is something you want to hilight. Don't try
to hide the assignment in the if statement where it is easier to miss
than if it had it's own line of code.
You can see from the format of the code that I like to understand one
simple
thing at a time then go onto the next thing.
In examples to folks who are not as familiar with program, I believe
it is best to code things in an easy to understand format and avoid
coding styles that many programs have noted as problematic. Look at
the code posted to this forum and note the problems with it.
Even though you may like using an assignment statement in an if
statement many programmer have found it troublesome. I assume this
must be getting at something. Best to avoid troublesome situations.
Thanks for you other comments.
You are a great asset to this forum.
Robert sp******@yahoo.com (simina) wrote in message news:<88**************************@posting.google. com>... I tried too but in a different manner...
Hope it helps:
<form>
<input type="text" name="myText" value="a">
<input type="button" name="myButton" onClick="return
myfunction(this.form);">
</form>
<script language="JavaScript1.2" type="text/javascript">
Language has been depreciated in favor of type.
<script type="text/javascript">
Best to leave out JavaScript1.2. Version 1.2 acted a little different
from the other versions of Javascript.
function myfunction(frm)
{
frm.myText.value = "b";
}
</script>
If you don't want the "a" to be in a text field, but just a text I
don't konw how to do it...
S.
This is valid:
<input type="text" name="myText" value="">
You should start a new thread if this is not what you are looking for.
I do not understand this comment:
but just a text
I assume you meant a blank text field.
You can hide the input field until you need it. Ask again if this is
what you wanted.
Robert
Robert wrote: Richard Cornford wrote:
<snip> Moving the assignment expression outside of the - if -
statement means having a second - if/else - inside the
- else - clause of a first. Whatever might be gained in
attempting to clarify that one - if - statement can be
weighed against losing the clear one-of-three structure
You have to mentally insert the assignment statement and
realize that it isn't a conditional thing.
Maybe it takes the realisation that the - if - statement evaluates an
expression and that only a small sub-set of expressions are 'conditional
things'. An assignment is just as much an expression as any other, and
has a well-defined result. Hence:- a = b = c = d = null; - ( or
parenthesised: - a = (b = (c = (d = null))); -)
My thought process is that I have to push the if statement
down in my thinking. Remember the assignment. Then, I have
to recall the if statement. You can see from my formatting
of the code. That I do not have to do this mental activity
because it is written on paper.
At least for me, I have to do the translation in my head.
It is more complicated for me to understand.
Humans vary considerably in the way they view, model and perceive the
world, and there is no doubt in my mind that that is a good thing (there
wouldn't be nearly as much invention if everyone's perceptions were
identical). Where you see this change as a clarification of the testing
logic I see it as an obscuring of the structure of the testing. Which
was originally a clear one choice of three and is now two nested choices
of two (the outcome is the same but my preference was for the former).
<snip> I reformulated the logic here.
var node = domCore.getElementById(label);
if(node)
{
var child;
if('string' == typeof node.innerHTML)
{
node.innerHTML = text.value;
}
else
{
child = node.firstChild;
if(child)
{
child.data = text.value;
}
else if(document.createTextNode &&
node.appendChild)
{
node.appendChild(
document.createTextNode(text.value));
}
}
}
Shows clearly:
1) What goes with what
2) code parrallels the oder the machine will run the code.
You do not have to back scan in the if statment nor do
mental push and pop operations.
While computer languages all exhibit operator precedence in one form or
another I don't think there are many programmers who learn (all of) the
precedence in any language they work with. Preferring instead to use the
appropriate placement of parentheses to make the desired sequence of
operations both certain and obvious.
I don't see the mental operations involved in comprehending a
parenthesised complex mathematical operation as significantly different
from that involved in comprehending a logical expression or if
expressions that contains assignment expressions (appropriately
parenthesised).
3) avoids the confusion over = and ==
There is no doubt that they are often confused, though mostly by those
unfamiliar with javascript (and the many other languages that use the
two). And JavaScript 1.2 confused matters even more by considering an
assignment directly within an - if - statement's expression as
comparison instead. And JSLINT will not put up with it, *unless* the
assignment is parenthesised (which also has JavaScript 1.2 treat it as
assignment).
4) Hilights the assignment statement because is valid for
the rest of the code block. It is valid outside the rest
of the if statement. I believe this reason alone is something
you want to hilight. Don't try to hide the assignment in the if
statement where it is easier to miss than if it had it's own
line of code.
While the results of the assignment do indeed stand for the remainder of
the execution following it the value assigned to - child - (the fact
that it has been assigned a value at all) is only of significance within
the one branch of the original code guarded by the - if - statement in
which the assignment happened. So it might be argued that placing the
assignment in the - if - expression more closely/directly associates it
with the code that may employ the result.
You can see from the format of the code that I like to
understand one simple thing at a time then go onto the
next thing.
Fair enough. But consider how some alternative structures might be
effected by this type of re-structuring. For example, suppose an
initial - if - branch was conditional on two assignments:-
var a, b;
if(
(a = getA()) &&
(b = getB())
){
// do something with a and b
}else{
//default action on failure
}
- once you re-structure it to get the assignments out of the - if -
expressions you get something like this:-
var b, a = getA();
if(a){
b = getB();
if(b){
// do something with a and b
}else{
// default action on failure
}
}else{
// default action on failure
}
- in which the - else - code has been doubled-up.
Make that three assignments and:-
var a, b, c;
if(
(a = getA()) &&
(b = getB()) &&
(c = getC())
){
// do something with a, b and c
}else{
// default action on failure
}
- becomes:-
var c, b, a = getA();
if(a){
b = getB();
if(b){
c = getC();
if(c){
// do something with a, b and c.
}else{
// default action on failure
}
}else{
// default action on failure
}
}else{
// default action on failure
}
- and it is looking like the - else - code is going to need passing off
to a parameterised function call to avoid the repetition (with the
consequence that what was previously directly visible code is moved
elsewhere, hardly a contribution to clarity).
And now if the - else - code itself branches, two branches become six.
That looks like escalating complexity to me.
There are alternative structures that could avoid repeating the - else -
code, such as flagging the success of the nested - if - blocks:-
var success = false, c, b, a = getA();
if(a){
b = getB();
if(b){
c = getC();
if(c){
success = true;
// do something with a and b
}
}
}
if(!success){
//default action on failure
}
- in which success cannot short-circuit the test for success and an
extra local variable has been added to the context.
However, returning from the function within the innermost - if -
branch:-
var c, b, a = getA();
if(a){
b = getB();
if(b){
c = getC()
if(c){
// do something with a, b and c
return; // avoid the default action by
// returning here.
}
}
}
// default action on failure (because the function did
// not return above)
- will short-circuit the default code and remove the necessity to test
for success/failure. But now the entire default action code is outside
any branching structure and someone missing the return statement might
waste time wondering why it is applied on each execution of the
function. Indeed there is quite a lot of debate about how and where
functions should return, centred around source code clarity, and the
above structure illustrates the case for claming that returning from
anywhere but the end of a function is less than clear.
In examples to folks who are not as familiar with program,
I believe it is best to code things in an easy to understand
format and avoid coding styles that many programs have noted
as problematic. Look at the code posted to this forum and
note the problems with it.
Even though you may like using an assignment statement in
an if statement many programmer have found it troublesome.
I assume this must be getting at something. Best to avoid
troublesome situations.
For a novice there probably are advantages in seeing code that is clear
on the level of individual expressions. Hopefully I have made a case for
suggesting that code written to be clear at that level might be
detracting form clarity and simplicity at a higher (structural) level.
In learning javascript there must come a point where the individual
expressions become second nature and interest moves on to the bigger
picture. It wouldn't be fair or reasonable to insist that all code
posted to the group catered for a lowest common denominator javascript
novice, and under those circumstances a lot of very interesting code
would never get the wider public exposure it deserves.
Richard.
On Sat, 25 Sep 2004 18:41:40 +0100, Richard Cornford
<Ri*****@litotes.demon.co.uk> wrote: Michael Winter wrote:
[snip]
var e = document.all[n], i = e.length; ^
Isn't it a bit premature to be assuming that the - document.all -
collection has returned something at this point?
Oops.
This is a new version of old code. Whilst fiddling with the .all section,
I must have removed that test without realising.
[snip]
var e = (document.all[id] || {} );
I'd probably choose that.
if(isN(i)) {while(i--) {if(e[i].id == n) return e[i];}}
else if(e.id == n) {return e;}
return null;
}
: function() {return null;}
});
})();
function(n) {
/* I would use l (L) instead of m, but it won't
* show very distinctly in most news readers.
*/
var e = document.all[n] || {}, m = e.length;
if(isN(m)) {
for(var i = 0;i < m; ++i) {if(e[i].id == n) {return e[i];}}
} else if(e.id == n) {return e;}
return null;
}
would probably be better. This way the first, not the last, matching
element would be returned. A more expected result. Of course, nothing
should really be expected with two or more matches: null is just as
correct in the eyes of DOM Core. It's just not very useful.
[snip]
Mike
--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Richard Cornford wrote: var a, b, c;
if(
(a = getA()) &&
(b = getB()) &&
(c = getC())
){
// do something with a, b and c
}else{
// default action on failure
}
- becomes:-
var c, b, a = getA();
if(a){
b = getB();
if(b){
c = getC();
if(c){
// do something with a, b and c.
}else{
// default action on failure
}
}else{
// default action on failure
}
}else{
// default action on failure
}
- and it is looking like the - else - code is going to need passing off
to a parameterised function call to avoid the repetition (with the
consequence that what was previously directly visible code is moved
elsewhere, hardly a contribution to clarity).
Or:
var c, b, a = getA();
if(a){
b = getB();
}
if (b) {
c = getC();
}
if (c) {
// do something with a, b and c.
} else {
// default action on failure
}
Which has the advantage that the tests can be re-ordered, or new tests
added, without significantly affecting the underlying logic.
It also has as an advantage that if there are many tests to be performed,
you do not end up with multiple levels of indentation.
Of course, your first code example already provides these advantages.
Still, I believe there are places where this modified gauntlet is a good
structure, although perhaps not in this particular example.
For the OP, a bit more on gauntlets here: <url: http://mindprod.com/jgloss/gauntlet.html />
--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq
Robert wrote: 2) There is no need for javascript: in an event handler. Javascript is
assumed in all event handler such as onclick.
No, it is not. In fact, it is only where the default scripting language
is J(ava)Script. However, the default scripting language should be defined
explicitely when using intrinsic event handler attributes:
<meta http-equiv="Content-Script-Type" content="text/javascript">
However, especially IE does not care about this declaration; instead,
it uses the scripting language of the last script element instead.
To workaround this bug, M$ has introduced the abuse of labels in event
handler attribute values to specify the scripting language. However,
this only works in IE and is a proprietary approach that should not
be pursued on the Web.
3) It is best to put quotes around the javascript code in an event
handler. onClick="myfunction();"
More, it is *required* as of SGML:
<http://www.w3.org/TR/REC-html32#sgml>
<http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2>
4) It is best to put in the trailing semi-colon ";".
It does not make a real difference whether the trailing semicolon
is included in the attribute value or not. In fact, the "overhead"
that is saved if the trailing semicolon is omitted is compensated
by the then-required built-it automatic semicolon insertion process
as specified in ECMAScript.
PointedEars
--
Andre the Giant has some coffee
On Sun, 10 Oct 2004 17:08:45 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote: Robert wrote:
2) There is no need for javascript: in an event handler. Javascript is
assumed in all event handler such as onclick.
No, it is not. In fact, it is only where the default scripting language
is J(ava)Script.
Which is in all user agents that assume a default.
<meta http-equiv="Content-Script-Type" content="text/javascript">
This bogus, and until the HTML WG respond to the comments against it,
it doesn't even have much weight of standard, it's certainly not an
http-equiv header.
To workaround this bug, M$ has introduced the abuse of labels in event
handler attribute values to specify the scripting language.
This predates the HTML WG's bogosity.
However,
this only works in IE and is a proprietary approach that should not
be pursued on the Web.
Agreed, but it's harmless, as is the meta-equiv of course, but that's
just bogus irrelevance.
Jim.
Jim Ley wrote: [...] Thomas 'PointedEars' Lahn [...] wrote: Robert wrote: 2) There is no need for javascript: in an event handler. Javascript is
assumed in all event handler such as onclick.
No, it is not. In fact, it is only where the default scripting language
is J(ava)Script.
Which is in all user agents that assume a default.
That is a bold statement. You have tested all user agents in questions, all
versions of them with all OSes on all platforms? If not, you should be
more careful with generalizations like "all".
<meta http-equiv="Content-Script-Type" content="text/javascript">
This bogus,
It is not bogus.
and until the HTML WG respond to the comments against it,
it doesn't even have much weight of standard,
The exact opposite is true. It has much weight of a standard until there
is an official consensus among the HTML WG that it should be removed from
or altered in the HTML 4.01 Specification:
<http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.2.1>
it's certainly not an http-equiv header.
(There is no "http-equiv" header.) It is true that "Content-Script-Type"
is not an HTTP/1.0 or HTTP/1.1 header, but that does not invalidate the
Recommendation. There is no "text/javascript" MIME media type registered
at IANA, for example, however it is recommended, in this group too, to use
it because there is not a widely supported alternative.
To workaround this bug, M$ has introduced the abuse of labels in event
handler attribute values to specify the scripting language.
This predates the HTML WG's bogosity.
That does not matter here.
However, this only works in IE and is a proprietary approach that should
not be pursued on the Web.
Agreed, but it's harmless,
It is not. A script engine that does not support labels will yield a syntax
script error here. Since the used script engine is an unknown factor on
the Web, it cannot be recommended to pursue that proprietary approach.
[...] but that's just bogus irrelevance.
(Script) Errors that can be avoided are never irrelevant.
PointedEars
--
No matter who you vote for, government always wins.
On Sun, 10 Oct 2004 18:01:53 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote: and until the HTML WG respond to the comments against it,
it doesn't even have much weight of standard,
The exact opposite is true. It has much weight of a standard until there
is an official consensus among the HTML WG that it should be removed from
or altered in the HTML 4.01 Specification:
No, there is an open issue against it, the WG must respond to issues
in their specifications, they have not responded to this one in many
months, this means that there is clearly not consensus (if there was,
they'd've been able to respond to the issue instantly)
(There is no "http-equiv" header.) It is true that "Content-Script-Type"
is not an HTTP/1.0 or HTTP/1.1 header, but that does not invalidate the
Recommendation.
What Recommendation? It's a bogus header, that achieves nothing - the
HTML WG will not respond to comments despite being required to (and
yes there's a problem in W3 Process that doesn't put a time limit on
responses - I have an issue against that too, currently 11 months
old...)
The HTML WG did not have the required 1 implementation of the header
at the time of specification, it's bogus.
There is no "text/javascript" MIME media type registered
at IANA, for example, however it is recommended, in this group too, to use
it because there is not a widely supported alternative.
Because there's a good reason for this, there is no reason to include
the bogus header.
It is not. A script engine that does not support labels will yield a syntax
script error here.
So that would be a non ECMAScript conformant script engine, which are
the only things relevant to default intrinsic events, this is not a
problem.
Bogus, crap reccomendations are not things to promote, they lock in
poor choices, such as the meta header you're discussing, don't blindly
support bad decisions, especially ones with open issues against like
this.
Jim.
Jim Ley wrote: [...] Thomas 'PointedEars' Lahn [...] wrote: and until the HTML WG respond to the comments against it,
it doesn't even have much weight of standard,
The exact opposite is true. It has much weight of a standard until there
is an official consensus among the HTML WG that it should be removed from
or altered in the HTML 4.01 Specification:
[...] they have not responded to this one in many months, this means that
there is clearly not consensus [...]
Exactly, and because of that what the HTML 4.01 Specification says
is still kind of a standard. Thank you for proving me right.
(There is no "http-equiv" header.) It is true that "Content-Script-Type"
is not an HTTP/1.0 or HTTP/1.1 header, but that does not invalidate the
Recommendation.
What Recommendation?
The HTML 4.01 Recommendation and the section of it I am referring to the
whole time.
It's a bogus header, that achieves nothing -
Do you have *any* strong proof for that bold statement? If not, I suggest
you be still, for it could be perceived as a nonsensical statement if
repeated. There is no "text/javascript" MIME media type registered
at IANA, for example, however it is recommended, in this group too, to us
eit because there is not a widely supported alternative.
Because there's a good reason for this, there is no reason to include
the bogus header.
You are missing the point, i.e. that there are widely used features that
are not standardized or registered but work anyway because they are widely
supported as well. It is not. A script engine that does not support labels will yield a
syntax script error here.
So that would be a non ECMAScript conformant script engine, [...]
Wrong. Labels (or, more precisely, labelled statements; in the
ECMAScript grammar: LabelledStatements) have been introduced in
ECMAScript 3. There have been two more editions prior without
that feature which compliant scripting languages and engines are
based upon. And there have been several JavaScript and JScript
language versions that did not provide the feature.
PointedEars
--
It's not what the W3C standard specifies. But seamonkey see, seamonkey do.
On Sun, 10 Oct 2004 20:36:37 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote: Jim Ley wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote: and until the HTML WG respond to the comments against it,
it doesn't even have much weight of standard,
The exact opposite is true. It has much weight of a standard until there
is an official consensus among the HTML WG that it should be removed from
or altered in the HTML 4.01 Specification:
[...] they have not responded to this one in many months, this means that
there is clearly not consensus [...]
Exactly, and because of that what the HTML 4.01 Specification says
is still kind of a standard. Thank you for proving me right.
No, since if that was the case, responding to the issue would've been
trivial, and wouldn't've taken so long.
It's a bogus header, that achieves nothing -
Do you have *any* strong proof for that bold statement?
Proof of what, that's bogus, I can't see what I could provide other
than the absence of the WG's explanation in response of the issues
against it, of that it achieves nothing, sure the fact that all but an
insignificant minority of pages don't have it and they all work in all
user agents.
You are missing the point, i.e. that there are widely used features that
are not standardized or registered but work anyway because they are widely
supported as well.
Yep, such as javascript being the default script language for
intrinsic events.
It's not what the W3C standard specifies. But seamonkey see, seamonkey do.
An interesting sig. Given that you're arguing for blinding following
a W3C standard when it has no benefit, and I'm saying, follow the
de-facto standard.
Jim.
Jim Ley wrote: [...] Thomas 'PointedEars' Lahn [...] wrote: Jim Ley wrote: [...] Thomas 'PointedEars' Lahn [...] wrote:
> and until the HTML WG respond to the comments against it,
> it doesn't even have much weight of standard,
The exact opposite is true. It has much weight of a standard until
there is an official consensus among the HTML WG that it should be
removed from or altered in the HTML 4.01 Specification:
[...] they have not responded to this one in many months, this means
[that
there is clearly not consensus [...] Exactly, and because of that what the HTML 4.01 Specification says
is still kind of a standard. Thank you for proving me right.
No, since if that was the case, responding to the issue would've been
trivial, and wouldn't've taken so long.
You are hedging. There is no official consensus among the WG and so the
last edition of the HTML 4.01 Specification is the only valid reference
on this topic.
It's a bogus header, that achieves nothing -
Do you have *any* strong proof for that bold statement?
Proof of what, that's bogus, [...]
Yes, strong proof of that, exactly. That would include a long list of
positive UA tests, but then I don't expect you to ever provide it.
You are missing the point, i.e. that there are widely used features that
are not standardized or registered but work anyway because they are
widely supported as well.
Yep, such as javascript being the default script language for
intrinsic events.
No, that depends on the UA.
It's not what the W3C standard specifies. But seamonkey see, seamonkey
do.
An interesting sig. Given that you're arguing for blinding following
a W3C standard when it has no benefit,
1. I am not arguing for blinding following a W3C standard (better: a W3C
Recommendation). If you would have read my posting(s) thoroughly, you
would have known. For example, I disregard the Recommendation's section
that says "script" element's content should be commented out, for I know
that there is no (quasi-)standards compliant HTML UA out there that does
not support the "script" element (as I have proven prior.)
2. That this feature does not have a benefit remains to be proven.
Since you state that it does not have one, you are the one to prove it.
If you cannot prove it or you are not willing to do so, your statement
remains false, and: By repeating false statements (over and over again)
they do not become more true. [psf 4.18] Period.
and I'm saying, follow the de-facto standard.
Which I do in this case. The (HTML 4.01) Recommendation is
the de-facto standard; your unproved allegations are not.
PointedEars
--
Question: How do you fix a bug? Is it A) Step on it. B) Delete random lines
of code. C) Buy a new computer. or D) Whats a bug?. Is that your final
answer?
On Sun, 10 Oct 2004 21:13:13 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote: You are hedging. There is no official consensus among the WG and so the
last edition of the HTML 4.01 Specification is the only valid reference
on this topic.
No, that's the point of an issue against a specification - the
specification isn't clear, or is dubious in its nature etc. hence the
issue - The element is suspect until the issue is resolved. (like a
law that is being reviewed by a constitutional court, the law is
suspect)
Yes, strong proof of that, exactly. That would include a long list of
positive UA tests, but then I don't expect you to ever provide it.
Lots of UA tests wouldn't prove it, there'd always be another UA, so
that proof method wouldn't be acceptable to me. Yep, such as javascript being the default script language for
intrinsic events.
No, that depends on the UA.
No it does not! Or prove it... (please don't actually bother...)
Jim.
Thomas 'PointedEars' Lahn wrote: Jim Ley wrote: [...] Thomas 'PointedEars' Lahn [...] wrote:
<snip> It's a bogus header, that achieves nothing -
Do you have *any* strong proof for that bold statement?
Proof of what, that's bogus, [...]
Yes, strong proof of that, exactly. That would include a
long list of positive UA tests, but then I don't expect you
to ever provide it.
You have got your logic the wrong way around here. Evan an infinite list
of browsers that pay no heed to the bogus META element, or any
corresponding HTTP header, could not _prove_ that the header was bogus.
However, just one example of a browser that did take some significant
action in the presence of the META element (or HTTP header) that it
would not take in the absence of the same, would logically falsify the
assertion that the META/header is bogus. But realistically, the onus is
on you to find that one example. Otherwise the fact that nobody else has
ever cited such a browser (and in a community with quite a curiosity
about the diversity of web browsers) supports the theory that no such
browser exists.
<snip> 2. That this feature does not have a benefit remains to be
proven. Since you state that it does not have one, you
are the one to prove it. If you cannot prove it or you
are not willing to do so, your statement remains false,
and: By repeating false statements (over and over again)
they do not become more true. [psf 4.18] Period.
It is not possible to prove anything logically. But any non-metaphysical
theory can be demonstrated to be false (disproved) if it is false. You
are the one asserting that the theory is false so the onus is on your to
present the evidence that disproves it.
Richard.
Jim Ley wrote: [...] Thomas 'PointedEars' Lahn [...] wrote: You are hedging. There is no official consensus among the WG and so the
last edition of the HTML 4.01 Specification is the only valid reference
on this topic.
No, that's the point of an issue against a specification - the
specification isn't clear, or is dubious in its nature etc. hence the
issue - The element is suspect until the issue is resolved. (like a
law that is being reviewed by a constitutional court, the law is
suspect)
That still does not invalidate the Specification.
It makes it to be questioned, that's all. And that is good so.
Yes, strong proof of that, exactly. That would include a long list of
positive UA tests, but then I don't expect you to ever provide it.
Lots of UA tests wouldn't prove it, there'd always be another UA, so
that proof method wouldn't be acceptable to me.
So you agree that there is no method to provide a strong proof
that your bold statement is true and thus it must be false. Fine.
Yep, such as javascript being the default script language for
intrinsic events.
No, that depends on the UA.
No it does not!
It depends on the UA, since it depends on the script engine used by (and
available for) this app. If you would understand a first thing about what
is a user agent, you would not be stamping your foot.
Or prove it...
Use
<script type="text/vbscript" language="VBScript">
Dim x
</script>
prior to an intrinsic event handler attribute value in IE, and
you have the proof. Even if that would not work as expected,
it would be pretty clear that it depends on the interpreting
software what the default scripting language is.
(please don't actually bother...)
You are the one to still bother about proving your statements,
not me.
PointedEars
--
C1999: Too much bloat: Shoot programmer
Richard Cornford wrote: Thomas 'PointedEars' Lahn wrote: 2. That this feature does not have a benefit remains to be
proven. Since you state that it does not have one, you
are the one to prove it. If you cannot prove it or you
are not willing to do so, your statement remains false,
and: By repeating false statements (over and over again)
they do not become more true. [psf 4.18] Period.
It is not possible to prove anything logically.
This is utter nonsense or as you would call it, "Bullshit!"
But any non-metaphysical theory can be demonstrated to be false
(disproved) if it is false. You are the one asserting that the
theory is false so the onus is on your to present the evidence
that disproves it.
I have not stated it is "bogus", Jim has. However, I have the
Recommendation of a supposed-to-be competent HTML WG that resulted in a
public Specification and no convincing proof that makes me to disbelieve
it/them: My UAs, i.e. the UAs I have tested with, are not necessarily the
most standards compliant ones, even if they call themselves standards
compliant or work in a Standards Compliance Mode.
EOD
PointedEars
--
Life's a complicated gig, so give that ol' Dark Night of the Soul a hug, and
howl the eternal YES!
Thomas 'PointedEars' Lahn wrote: Richard Cornford wrote:
<snip> It is not possible to prove anything logically.
This is utter nonsense or as you would call it, "Bullshit!"
I take it the study of epistemology has remained outside of your
experience to date. But any non-metaphysical theory can be demonstrated to be
false (disproved) if it is false. You are the one asserting
that the theory is false so the onus is on your to present
the evidence that disproves it.
I have not stated it is "bogus", Jim has.
<snip>
Yes, that was Jim's assertion. Stronger wording I would have used, but
not a statement that can be dismissed for that reason.
Jim's assertion corresponds with all available empirical evidence, is
refutable (in that one example of a browser that cared about the META
element, or corresponding HTTP header, would disprove it (thus avoiding
it being categorised as metaphysical [1])), and is yet to be refuted.
And that (much as I expect you not to recognise it) is the criteria for
a scientific[2] 'truth'; a theory. It is not possible to know that such
a theory is true (it cannot be proved), but it is possible to know that
it is false (if it were), because it _is_ refutable.
You can assert that Jim's statement is false (and deduce that on any
irrational gourds you like) but _if_ Jim's statement is false you would
be in a position to disprove (refute, or falsify) it.
Richard.
[1] Being irrefutable (in a non-rhetorical sense) is the quality that
defines the metaphysical. It isn't a good quality for an assertion to
possess because it just means that nothing can be decided about it one
way or another, ever.
[2] On these criteria science progresses through the creation of new
theories that accurately describe the available evidence, and the
elimination of those (and existing theories) by their refutation
(falsification, or disproving). Thus the problem that it is impossible
to prove anything true is avoided because the totality of scientific
knowledge becomes more-true (less-false) over time through the
elimination of the false theories.
Richard Cornford wrote: Thomas 'PointedEars' Lahn wrote: Richard Cornford wrote:
<snip> It is not possible to prove anything logically.
This is utter nonsense or as you would call it, "Bullshit!"
I take it the study of epistemology has remained outside of your
experience to date.
I take it that you want to read
<http://en.wikipedia.org/wiki/Logical_argument> pp.
PointedEars
Thomas 'PointedEars' Lahn wrote: Richard Cornford wrote: Thomas 'PointedEars' Lahn wrote: Richard Cornford wrote:
<snip> It is not possible to prove anything logically.
This is utter nonsense or as you would call it, "Bullshit!"
I take it the study of epistemology has remained outside
of your experience to date.
I take it that you want to read
<http://en.wikipedia.org/wiki/Logical_argument> pp.
No, it is a less than authoritative article that skirts the issue.
Reading it contributed nothing.
Richard.
> > Lots of UA tests wouldn't prove it, there'd always be another UA, so that proof method wouldn't be acceptable to me.
So you agree that there is no method to provide a strong proof
that your bold statement is true and thus it must be false. Fine.
are you calling true what you cannot prove false???? People used to get
butned on the stakes thanks to people like that!!!
--
Hope that helps,
Phil
http://uk.geocities.com/philippeoget
philippeoget at yahoo dot com
Programming Excel: <a
href="http://uk.geocities.com/philippeoget/xl/InternetLinkOrganiser.zip"
target="_blank">The Excel A2Z Project: </a>
http://uk.geocities.com/philippeoget/a2z/
"Thomas 'PointedEars' Lahn" <Po*********@web.de> wrote in message
news:29****************@PointedEars.de... Jim Ley wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote: You are hedging. There is no official consensus among the WG and so
the last edition of the HTML 4.01 Specification is the only valid reference
on this topic.
No, that's the point of an issue against a specification - the
specification isn't clear, or is dubious in its nature etc. hence the
issue - The element is suspect until the issue is resolved. (like a
law that is being reviewed by a constitutional court, the law is
suspect)
That still does not invalidate the Specification.
It makes it to be questioned, that's all. And that is good so.
Yes, strong proof of that, exactly. That would include a long list of
positive UA tests, but then I don't expect you to ever provide it.
Lots of UA tests wouldn't prove it, there'd always be another UA, so
that proof method wouldn't be acceptable to me.
So you agree that there is no method to provide a strong proof
that your bold statement is true and thus it must be false. Fine.
Yep, such as javascript being the default script language for
intrinsic events.
No, that depends on the UA.
No it does not!
It depends on the UA, since it depends on the script engine used by (and
available for) this app. If you would understand a first thing about what
is a user agent, you would not be stamping your foot.
Or prove it...
Use
<script type="text/vbscript" language="VBScript">
Dim x
</script>
prior to an intrinsic event handler attribute value in IE, and
you have the proof. Even if that would not work as expected,
it would be pretty clear that it depends on the interpreting
software what the default scripting language is.
(please don't actually bother...)
You are the one to still bother about proving your statements,
not me.
PointedEars
--
C1999: Too much bloat: Shoot programmer
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Scott |
last post by:
I am trying to alter the ForeColor of a TextBox object so
that parts of the displayed text are written in various
colors. For example, when writing to the TextBox I wish
to display parts of the...
|
by: Rob Heckart |
last post by:
Hi,
I'm using the Portal ASP.NET starter kit for a project. It uses one aspx
page, DesktopDefault.aspx to render content by loading different user
controls depending on what's clicked. One of my...
|
by: Jeff |
last post by:
....still new at this. ...hopefully a simple question
Is there some practical way of altering the function of a keypress in Visual Web.net 2005 using VB without causing a postback on
each...
|
by: Klaus Jensen |
last post by:
Hi
I am trying to post-process some XML-documents from some third-party
software.
I open them, find the right element, manipulate the text and write it back
to the element.
|
by: JimmyKoolPantz |
last post by:
IDE: Visual Studio 2005
Language: VB.NET
Fox Pro Driver Version: 9.0.0.3504
Problem: I currently have a problem altering a DBF file. I do not get
any syntax errors when running the program. ...
| | |
by: dohboy |
last post by:
a kinda newbie here.
I've done a simple little program that reads a text file and counts the number of lines and words.
I had a heck of a time getting it to count properly when I finally discovered...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| | |
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
