By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,273 Members | 1,037 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,273 IT Pros & Developers. It's quick & easy.

Disable Drop-box Based On Users Selection

P: n/a
Hi All

I'm new to javascript and was wondering if someone can help me with
this I want to disable my second and third drop-box if the first one
is selected to "Closed" I think I'm close but just cant get it to work
here is my code:
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF" text="#000000">

<script>
function DisableMondayDropdown(bool)
{
if(document.Monday.Hours == "Closed"){
document.Monday.Hours1.disabled=bool;
document.Monday.Hours2.disabled=bool;
}
}
</script>

<form name=Monday onChange="DisableMondayDropdown(true)">
<select name=Hours>
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
<option value=Closed>Closed
</select>

<select name=Hours1>
<option value=1>1
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
</select>

<select name=Hours2>
<option value=1>1
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
</select>

</form>

</body>
</html>

If you can help thanks in advance
Blnukem
Jul 20 '05 #1
Share this Question
Share on Google+
30 Replies


P: n/a
On 18 Jan 2004 08:01:11 -0800, Blnukem <bl*****@hotmail.com> wrote:
Hi All

I'm new to javascript and was wondering if someone can help me with
this I want to disable my second and third drop-box if the first one
is selected to "Closed" I think I'm close but just cant get it to work
here is my code:
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF" text="#000000">

<script>
The type attribute is required in SCRIPT elements. You should change this
to

<script type="text/javascript">
function DisableMondayDropdown(bool)
{
if(document.Monday.Hours == "Closed"){
I would normally recommend here that you change the above form reference to

document.forms['Monday'].elements['Hours']

however, I'm sure Mr Webb would have something to say about it[1], so I'll
just say that in some circumstances (certainly when id attributes are
involved), the above syntax will work with more browsers.
document.Monday.Hours1.disabled=bool;
document.Monday.Hours2.disabled=bool;
}
}
</script>
I certainly recommend that you enclose all attribute values in quotes.
<form name=Monday onChange="DisableMondayDropdown(true)">
The FORM element doesn't have an onchange intrinsic event. However, SELECT
elements do, and that's where you want to place the attribute.
<select name=Hours>
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
<option value=Closed>Closed
</select>


<snip>

Once you make those alterations, you'll be closer to your goal. However,
you'll notice that there's no way to re-enable the controls you disabled.
Below is a function that you can use instead (renamed to fit its new
functionality).

function toggleMondayDropdown() {
// Get a reference to the form
var mondayForm = document.forms['Monday'];
// If Hours is 'Closed', disable the controls (state is true)
var state = ('Closed' == mondayForm.elements['Hours'].value);

/*
The assignment to state, above, could also be written as:

var state;

if( 'Closed' == mondayForm.elements['Hours'].value )
{
state = true;
} else {
state = false;
}

if that makes the expression any clearer.
*/

mondayForm.elements['Hours1'].disabled = state;
mondayForm.elements['Hours2'].disabled = state;
}

Hope that helps,

Mike
[1] To Mr Webb: I concede that you have a point, but I still think my
reasoning is valid. Yes, one could use getElementById() when id attributes
are involved, but as not all browsers in use support it (that argument is
rapidly diminishing) and, in the case of form-enclosed controls, there
exists an alternative way to access id'd controls, I'll continue to use
the collection syntax. :)

If you prefer that I stop recommending it in cases where references use
names, not ids, then I shall (provided that the shortcut syntax *will*
work in all such cases when compared to the collection syntax).

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Jul 20 '05 #2

P: n/a
"Blnukem" <bl*****@hotmail.com> wrote in message
news:25**************************@posting.google.c om...
Hi All

I'm new to javascript and was wondering if someone can help me with
this I want to disable my second and third drop-box if the first one
is selected to "Closed" I think I'm close but just cant get it to work
here is my code:
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF" text="#000000">

<script>
function DisableMondayDropdown(bool)
{
if(document.Monday.Hours == "Closed"){
document.Monday.Hours1.disabled=bool;
document.Monday.Hours2.disabled=bool;
}
}
</script>

<form name=Monday onChange="DisableMondayDropdown(true)">
<select name=Hours>
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
<option value=Closed>Closed
</select>

<select name=Hours1>
<option value=1>1
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
</select>

<select name=Hours2>
<option value=1>1
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
</select>

</form>

</body>
</html>

If you can help thanks in advance
Blnukem


Minor changes:

1. compare value, not element, with "Closed"
2. apply onchange handler to the correct element (the select, not the form)

function CheckMondayDropdown()
{
//alert("In change handler");
document.Monday.Hours1.disabled=(document.Monday.H ours.value == "Closed");
document.Monday.Hours2.disabled=(document.Monday.H ours.value == "Closed");
}
</script>

<form name=Monday>
<select name=Hours onChange="CheckMondayDropdown()">
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
<option value=Closed>Closed
</select>
....

PS a handy tip is to add alerts e.g. alert("In change handler"); Had you
done that you would have seen that control was not reaching your onchange
handler.
Jul 20 '05 #3

P: n/a
Michael Winter wrote:
On 18 Jan 2004 08:01:11 -0800, Blnukem <bl*****@hotmail.com> wrote:

<--snip-->
{
if(document.Monday.Hours == "Closed"){

I would normally recommend here that you change the above form reference to

document.forms['Monday'].elements['Hours']

however, I'm sure Mr Webb would have something to say about it[1], so
I'll just say that in some circumstances (certainly when id attributes
are involved), the above syntax will work with more browsers.


I don't have a problem with people saying something like this:

If your form uses ID's, then you are safer using this syntax.

Or:

For future compatibility, start learning to use this syntax.

But, to say that its "better" than the other, when used with a name
attribute, is plain wrong.

This code:

<form id="myForm" action="">
<input type="text" value="my value" id="myInput">
<input type="button" value="Show Me"
onclick="alert(document.forms['myForm'].elements['myInput'].value)" </form>

Is utterly useless in NN4.xx and as long as its around (yes, its still
around), then the ID attribute shouldn't be used with a Form. Give it a
name, access it either way, and move on.
<--snip-->

[1] To Mr Webb: I concede that you have a point, but I still think my
reasoning is valid. Yes, one could use getElementById() when id
attributes are involved, but as not all browsers in use support it (that
argument is rapidly diminishing) and, in the case of form-enclosed
controls, there exists an alternative way to access id'd controls, I'll
continue to use the collection syntax. :)
I never said your reasoning for using the same syntax system wide was
flawed. I said your reasoning that document.forms['formName']..... was
better than document.formName...... when named forms are present was flawed.
If you prefer that I stop recommending it in cases where references use
names, not ids, then I shall (provided that the shortcut syntax *will*
work in all such cases when compared to the collection syntax).


Until a browser is found where it doesn't work, then either is valid
when used with a name.

How about something like this:
<FAQENTRY>
Q. How do I acces a form element?
A. If the elements have an ID, then use the forms collection:
document.forms[formID].elements[elementID]
Note: This fails in older browsers.

If the elements have a NAME attribute then you can use the forms
collection or the short cut syntax:

document.forms['formName'].elements['elementName']
or:
document.formName.elementName
</FAQENTRY>
Maybe in an expanded 4.13?

Richard:
Is it too late to get something like this incorporated in this round of
revisions to the FAQ? It seems to be coming up a lot recently.

--
Randy

Jul 20 '05 #4

P: n/a
Randy Webb <hi************@aol.com> writes:
But, to say that its "better" than the other, when used with a name
attribute, is plain wrong.
I like to think of "following the W3C DOM specification" as being better
than not. But yes, "better" is always subjective.
How about something like this:
<FAQENTRY>
Q. How do I acces a form element?
A. If the elements have an ID, then use the forms collection:
The problem is not that it has an ID. The problem is that it doesn't
have a name. If it has both, you can use both methods.

So, it should be: If the element *only* has an ID.
If the elements have a NAME attribute then you can use the forms
collection or the short cut syntax:

document.forms['formName'].elements['elementName']
or:
document.formName.elementName


I see no reason for recommending the second, except that it is shorter,
which I don't count as a qualification at all. If at all, I would
prefer to recommend:
document['formName']['elementName']
since that will get rid of the questions with " my input is called
'foo[]'".

But to keep the FAQ short, I would prefer to recommend only one
notation: the full, W3C DOM compliant, square-bracketed notation. If
people use it, it *will* work, and you won't need to mention the
exception at all ... and all are happy (I wish!).

Actually, I prefer to only refer to the form through the "form"
property of its controls, which again are captured as the "this"
property on handlers assigned to them. I only very rarely need
to refer to a from except from inside itself.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #5

P: n/a
"Randy Webb" <hi************@aol.com> wrote in message
news:pu********************@comcast.com...
<snip>
I don't have a problem with people saying something like this:

If your form uses ID's, then you are safer using this syntax.

Or:

For future compatibility, start learning to use this syntax.
I am not so sure that future-compatibility is going to be a worthwhile
argument, depending on which future is being talked about. With XHTML,
currently Mozilla seem very resistant to implementing the HTMLDocument
(from W3C HTML DOM) on the document object in their XHTML DOM (though
they are implementing the rest of the HTML DOM on the objects under it).
Without that interface all the convenience properties of the document
are gone including the forms collection.

Opera 7, OTOH have implemented HTMLDocument on their XHTML document but
I don't think we will know the shape of the XHTML DOM we will be using
until IE produce a browser that implements it (if ever). If they
implement HTMLDocument Mozilla will probably have to give in and follow
suite, if not then the convenience properties will no longer be usable.

In practice the XHTML future is still a long way off and given the
considerable differences between HTML scripting and XHTML scripting
(namespaces probably being the most significant) I don't see much point
in attempting to designing HTML scripts with compatibility with XHTML
DOMs in mind. Probably better to consider the transition to XHTML as a
watershed and leave worrying about the technicalities until XHTML
becomes practical (which means: supported by the majority of browsers,
if not all).
But, to say that its "better" than the other, when used
with a name attribute, is plain wrong.
Personally (and other issues aside) I like the:-

document.forms['myform'].elements['myEl']

- style of accessor for the clarity it brings to the source code.
Looking at it there is no question that the subject of the code is a
form and an element of that form. While a named property of the document
might be an image, an applet, an expando or a non-standard browser
feature. Also, I hadn't formalised my reasons for preferring square
bracket notation where the form and element names are concerned but
Lasse described the practice as keeping the separate namespaces
(HTML/DOM) distinct, which describes my feelings on the subject.

For those reasons I think that the longer form property accessors using
the collections are better, but that is a personal opinion.

<snip>... NN4.xx and as long as its around (yes, its still
around), then the ID attribute shouldn't be used with
a Form. Give it a name, access it either way, and move on.
Yes, their is no good excuse for writing code that interacts with forms
in an HTML document in a way that is not compatible with every browser
that understands forms, and certainly all of the browsers in use. It is
probably still the one area of browser scripting where one pattern can
fit all.

<snip><FA ... Y>
Q. How do I acces a form element?
A. If the elements have an ID, then use the forms collection:
document.forms[formID].elements[elementID]
Note: This fails in older browsers.

If the elements have a NAME attribute then you can use
the forms collection or the short cut syntax:

document.forms['formName'].elements['elementName']
or:
document.formName.elementName
</FA ... Y>
Maybe in an expanded 4.13?

Richard:
Is it too late to get something like this incorporated in this
round of revisions to the FAQ? It seems to be coming up a lot
recently.


I don't want to encourage people to inundate me with new FAQ requests at
this point but currently nothing is final and I am happy to entertain
additional suggestions.

Generally I agree with Lasse and think that:-

<draft>
4.nn How do I access a form element?
Named form elements may be referred to as named properties of
the document.forms collection and named form elements as named
properties of the form's elements collection in HTML documents.

document.forms['formName'].elements['elementName']
<link to something with more details on the issues>
</draft>

- might be the most that would be worth putting in the FAQ on the
subject as that will work. The other issues: anonymous forms/elements,
radio button collections, IDs, combining IDs and NAME attributes, XHTML
and getElementById and W3C HTML DOM compliance probably need to be
referred to in other documents else the posted FAQ risks becoming
enormous.

It would be nice to be able to incorporate this in 4.13 because the FAQ
in general is moving away form direct Netscape 4 support and currently
4.13 is specifically about that browser. Unfortunately changing 4.13 too
much is going to break every reference to it in all the articles in the
archives. I don't really want to do that. A compromise might be to make
it more general:-

<draft>
4.13 How do I get the value of a form element?
Named form elements may be referred to as named properties
of the document.forms collection and named form elements as
named properties of the form's elements collection in HTML
documents:

var el=document.forms['formname'].elements['elementname'];

The value property of such elements can be read directly
from the element:-

var value = el.value;

Except when the element is a SELECT element where it is
necessary to read the value property from the currently
selected OPTION element whenever compatibility with older
browsers (like NN 4) may be necessary:-

var value = el.options[el.selectedIndex'].value;
<link to something with more details on the issues>
</draft>

My suggestion for reconciling the need to keep the posted FAQ small and
the desire to provide the necessary detail, caveats and explanation is
to create a second document of notes on the FAQ and link to it from the
FAQ as necessary. I was thinking that whoever edited the FAQ would also
edit that document but anyone who perceived the need to write a note on
any part of the FAQ could contribute to it (even maybe reproduce some of
the more detailed explanations posted to the group (with the authors
permission) as notes). So if anyone feels like contributing an
explanation of the issues around this subject please do so.

Richard.
Jul 20 '05 #6

P: n/a
Richard Cornford wrote:
"Randy Webb" <hi************@aol.com> wrote in message
news:pu********************@comcast.com...
But, to say that its "better" than the other, when used
with a name attribute, is plain wrong.

Personally (and other issues aside) I like the:-

document.forms['myform'].elements['myEl']

- style of accessor for the clarity it brings to the source code.


Clarity is not always the #1 issue. A lot has been said in the last few
years about speed.
Looking at it there is no question that the subject of the code is a
form and an element of that form. While a named property of the document
might be an image, an applet, an expando or a non-standard browser
feature. Also, I hadn't formalised my reasons for preferring square
bracket notation where the form and element names are concerned but
Lasse described the practice as keeping the separate namespaces
(HTML/DOM) distinct, which describes my feelings on the subject. I don't want to encourage people to inundate me with new FAQ requests at
this point but currently nothing is final and I am happy to entertain
additional suggestions.
I agree, I know you have a ton of work on your hands as it is.

Generally I agree with Lasse and think that:-

<draft>
4.nn How do I access a form element?
Named form elements may be referred to as named properties of
the document.forms collection and named form elements as named
properties of the form's elements collection in HTML documents.

document.forms['formName'].elements['elementName']
<link to something with more details on the issues>
</draft>


Let me start by saying that I made the following page as a test. Which
ever one was the fastest, I was prepared to start using. It didn't
surprise me that shorthand was faster though, to be honest.
<URL:
http://members.aol.com/_ht_a/hikksno...est/index.html />

Is the test page I made to test ShortHand versus LongHand.

I am going to tinker with it some more as its doing 100,000 iterations.
Probably bring it back to 10,000 and loop it 10 times to get an average.
And if it turns out that longhand wins, I will start recommending it.

IE 6.0 - Shorthand
Opera 7 - Shorthand
K-Meleon - Shorthand
Netscape 7 - Long Hand
Mozilla 1.4 - Shorthand

Now, do we recommend clarity, or speed?

Personally, I prefer speed over any gain in clarity. If I need clarity,
I can comment it :)

--
Randy

Jul 20 '05 #7

P: n/a
"Randy Webb" <hi************@aol.com> wrote in message
news:QY********************@comcast.com...
<snip>
document.forms['myform'].elements['myEl']

- style of accessor for the clarity it brings to the source code.
Clarity is not always the #1 issue. A lot has been said in
the last few years about speed.


And a fair bit of it by me, so I have no right to dismiss the point. And
speed could be a reasonable criteria for "better".
<draft>
4.nn How do I access a form element?
Named form elements may be referred to as named ...

^^^^^^^^^^^^^^^^^^^
That should have read "named forms".

<snip>... . It didn't surprise me that shorthand
was faster though, to be honest.
Nor me.

<snip>And if it turns out that longhand wins,
I will start recommending it.
I don't think the longer version can win. It should take, on average, as
long to resolve - document.forms - as it would to resolve -
document.myForm - because they are both named properties of the same
object. So the additional forms.myForm resolution must always be on top
of that.

<snip>Now, do we recommend clarity, or speed?
I think we start with reliable. From there on we are clearly into the
realms of opinion, and we have:-

1. W3C HTML DOM conformance favouring the longer version
(though it is ambiguous whether it should allow the
shorthand of referring to the elements as named members
of the form, I still think it should).

2. Clarity in source code, favouring the longer version.

3. Execution speed due to the time taken to resolve the
references, favouring the shortcut version.

While I like to promote efficient code, and will even attempt to squeeze
every ounce of performance out of some scripts (mostly DHTML stuff), I
find it difficult to be concerned about the difference in the time it
would take to resolve the longer version against the shorthand. I would
habitually store a form reference in a local variable anyway so it is a
difference that would only apply once (per validation attempt or
whatever). It is also not often you see a form so big that even if each
and every element reference was absolute the difference between the two
property accessors would add up to half a second.

If it became a case where I had to pick one to go into the FAQ (which is
the case if it goes in at all) then it is still going to be the long
version (with bracket notation). The entry could have additional notes
mentioning that there are practical alternatives and that the shorthand
version is faster to resolve (along with all the other points). At this
moment I am not feeling motivated to write those notes, that may change
(or someone else might decide to save me the effort).

I notice that you didn't quote the modified 4.13, do I take that as
implying that you would prefer not to merge this with the existing 4.13
question? (I quite liked that idea)
Personally, I prefer speed over any gain in clarity. If I need
clarity, I can comment it :)


Richard.
Jul 20 '05 #8

P: n/a
JRS: In article <bu*******************@news.demon.co.uk>, seen in
news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted at Mon, 19 Jan 2004 04:59:12 :-

Generally I agree with Lasse and think that:-

<draft>
4.nn How do I access a form element?
Named form elements may be referred to as named properties of
the document.forms collection and named form elements as named
properties of the form's elements collection in HTML documents.

document.forms['formName'].elements['elementName']
<link to something with more details on the issues>
</draft>

- might be the most that would be worth putting in the FAQ on the
subject as that will work.

In reading this newsgroup, I see that many incomers seem substantially
ignorant of modularisation and collecting common code; perhaps they are
paid by the yard (an antique measurement, 0.9144m) of code.

ISTM, therefore, that it would be well to give the above as
Frm = document.forms['formName']
Ele = Frm.elements['elementName']
or similar, to give the clue that Frm can be used for getting other
elements.

Re FAQ 4.13 link : IIRC, that was a good one; or, more globally, the
third link in 3.2, http://devedge.netscape.com/library/manuals/2000/java
script/1.3/reference/, is/was good - better than the 1.5 version,
provided that it is used with care.

I suspect that it may be worth-while using a links-checker on the FAQ
from time to time; those not found can be given a temporary "where is
it" mark.
If the FAQ is getting a complete make-over, ISTM that it might be worth
classifying the contents of Sec. 4 by topics (which wasn't necessary
when it started). Possible topics include windows, strings, DOM, maths,
miscellaneous. One might, to avoid confusion, put the repositioned
answers in Sec 6, replace Sec 4 by its own index as at the top, and
change those links to lead to the answers in Sec 6.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; Win98.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
Jul 20 '05 #9

P: n/a
JRS: In article <QY********************@comcast.com>, seen in
news:comp.lang.javascript, Randy Webb <hi************@aol.com> posted at
Mon, 19 Jan 2004 02:03:55 :-

Personally, I prefer speed over any gain in clarity. If I need clarity,
I can comment it :)


Remembering that comment slows transmission and interpretation.
ISTM that one only rarely needs to use // for anything other than
comment-to-end-of-line, or /* for other than comment to next */.

String and RegExp literals, maybe; and easily avoidable in strings.

Could a Web page be written with two textareas and a button between,
such that a general or slightly restricted valid page could be copied
into the first, with the button causing a version without comment,
indentation, or multiple newlines to appear in the second?

(The impossible reverse would be very useful, though an indenter should
be possible).

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for 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.
Jul 20 '05 #10

P: n/a
Randy Webb <hi************@aol.com> writes:
Now, do we recommend clarity, or speed?
In a FAQ: Clarity, without exception.
Speed at most gets a foot note.
Personally, I prefer speed over any gain in clarity. If I need
clarity, I can comment it :)


In your own code, you are free to do as you prefer. :)

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #11

P: n/a
Lasse Reichstein Nielsen wrote:
Randy Webb <hi************@aol.com> writes:

Now, do we recommend clarity, or speed?

In a FAQ: Clarity, without exception.
Speed at most gets a foot note.


Then why do we recommend +varName to convert to a number when
parseInt/parseFloat(varName) is more concise?

http://www.jibbering.com/faq/#FAQ4_21

And yes, + is the preferred/recommended way.

Which is it? Clarity or Speed?
Personally, I prefer speed over any gain in clarity. If I need
clarity, I can comment it :)

In your own code, you are free to do as you prefer. :)


And I prefer to teach the most efficient/fastest method. See above.

--
Randy

Jul 20 '05 #12

P: n/a
Randy Webb <hi************@aol.com> writes:
Then why do we recommend +varName to convert to a number when
parseInt/parseFloat(varName) is more concise?
parseInt and parseFloat are not more concise because you have to tell
about the exceptions: the radix on parseInt and the acceptance of
garbage after the number on both.

The appropriately named Number function (part of the "conversion
family" also including Boolean and String) is easier to recognize
and understand. It does exactly the same as the prefix plus, and
the only difference is that it is one function call slower and
five characters longer.
http://www.jibbering.com/faq/#FAQ4_21

And yes, + is the preferred/recommended way.

Which is it? Clarity or Speed?


I would use Number there, for clarity. And maybe add a footnote saying
that prefix plus is equivalent and slightly faster, but should be used
with care to avoid writing "++" by accident.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #13

P: n/a
Richard Cornford wrote:
"Randy Webb" <hi************@aol.com> wrote in message
news:QY********************@comcast.com...
<snip>

<--snip-->

I think we start with reliable. From there on we are clearly into the
realms of opinion, and we have:- 1. W3C HTML DOM conformance favouring the longer version
(though it is ambiguous whether it should allow the
shorthand of referring to the elements as named members
of the form, I still think it should).
Fair enough, even though I personally thing too much weight/discussion
is given to W3C, ECMAScript, or any other "regulating body". <shrug>

2. Clarity in source code, favouring the longer version.
See my reply to Lasse, with regards to + versus parseInt. Every one of
us is quick to point out that its "better" to use + because it is
marginally faster.

Now, we are all saying "No, faster isn't better, clarity is" ???

3. Execution speed due to the time taken to resolve the
references, favouring the shortcut version.

While I like to promote efficient code, and will even attempt to squeeze
every ounce of performance out of some scripts (mostly DHTML stuff), I
find it difficult to be concerned about the difference in the time it
would take to resolve the longer version against the shorthand. I would
habitually store a form reference in a local variable anyway so it is a
difference that would only apply once (per validation attempt or
whatever). It is also not often you see a form so big that even if each
and every element reference was absolute the difference between the two
property accessors would add up to half a second.
In reality, none of the speed matters. Not with +, form references, or
any other methods. Not even eval <shudder>. If any one of us made a
simple test page that used all of the available ways to convert from a
string to a number, one time, none of us could see a difference. But
thats beside the point (Or not at least until you get into real heavy
dHTML apps).
If it became a case where I had to pick one to go into the FAQ (which is
the case if it goes in at all) then it is still going to be the long
version (with bracket notation). The entry could have additional notes
mentioning that there are practical alternatives and that the shorthand
version is faster to resolve (along with all the other points). At this
moment I am not feeling motivated to write those notes, that may change
(or someone else might decide to save me the effort).
As long as notes are made that with a NAME attribute that either way
works and that the shorthand is marginally faster, its fine.
I notice that you didn't quote the modified 4.13, do I take that as
implying that you would prefer not to merge this with the existing 4.13
question? (I quite liked that idea)

I think you are asking if I like the idea of merging the two, and I do.
Might be better in 4.39 where it already discusses bracket notation though.

Either place, or even linked to a website about it. I just think it
should be explained (both ways, along with both ways
advantages/drawbacks) how to access a form and its elements in the FAQ.
And then let the script author decide whether they want clarity or speed.

--
Randy

Jul 20 '05 #14

P: n/a
Lasse Reichstein Nielsen wrote:
Randy Webb <hi************@aol.com> writes:

Then why do we recommend +varName to convert to a number when
parseInt/parseFloat(varName) is more concise?

parseInt and parseFloat are not more concise because you have to tell
about the exceptions: the radix on parseInt and the acceptance of
garbage after the number on both.


Very true.
The appropriately named Number function (part of the "conversion
family" also including Boolean and String) is easier to recognize
and understand. It does exactly the same as the prefix plus, and
the only difference is that it is one function call slower and
five characters longer.
Slower yet more concise. Which is exactly my point.
http://www.jibbering.com/faq/#FAQ4_21

And yes, + is the preferred/recommended way.

Which is it? Clarity or Speed?

I would use Number there, for clarity. And maybe add a footnote saying
that prefix plus is equivalent and slightly faster, but should be used
with care to avoid writing "++" by accident.


Wait now, the FAQ (which is what this is all about) says to use +
because its faster but we want a new entry that uses a slower technique
for clarity?

But I tend to agree with you, in a sense, that 4.21 might benefit from a
little expansion into the clarity/speed side.

--
Randy

Jul 20 '05 #15

P: n/a
"Randy Webb" <hi************@aol.com> wrote in message
news:n8********************@comcast.com...
<snip>
I think we start with reliable. From there on we are clearly
into the realms of opinion, and we have:-
1. W3C HTML DOM conformance favouring the longer version
(though it is ambiguous whether it should allow the
shorthand of referring to the elements as named members
of the form, I still think it should).


Fair enough, even though I personally thing too much
weight/discussion is given to W3C, ECMAScript, or any
other "regulating body". <shrug>


I don't think we can get away from ECMA 262, its algorithms define what
is "correct" for the language. Not that there is much that can be done
if an interpreter is identified as objectively wrong. There are also
job/task specifications that vaguely call for coding to conform to
"applicable web standards" so there is some value in knowing what those
standards are, and their implications.
2. Clarity in source code, favouring the longer version.


See my reply to Lasse, with regards to + versus parseInt.
Every one of us is quick to point out that its "better" to
use + because it is marginally faster.


Incidentally, for clarity I usually wrap unary + operations in
parenthesise.
Now, we are all saying "No, faster isn't better, clarity is" ???
I think we are saying that when initially presenting the subject clarity
is better. But from then on an explanation including aspects like
efficient use (possibly of alternatives) would not be out of place.
Giving people enough to make informed decisions for themselves seems
like the ideal approach, unfortunately that will usually be impractical
within the quick answers section of the FAQ.

<snip>In reality, none of the speed matters.
I don't think I would consider it good style to write inefficient code
without some other definite justification for doing so. But the
comprehensibility for collages[1] of the resulting code would be one
justification, so long as the result wasn't ridiculously inefficient.
Not with +, form references, or any other methods.
Not even eval <shudder>. If any one of us made a simple test
page that used all of the available ways to convert from a
string to a number, one time, none of us could see a difference.
Human reaction time is about 0.4 seconds so anything that happens
quicker than that is going to be difficult to perceive. With code the
relevance of efficiency comes down to how all of the individual
imperceptibly fast statements add up.
But thats beside the point (Or not at least
until you get into real heavy dHTML apps).
Maybe the value in discussing and promoting fast implementation in
JavaScript is so that bad habits that are insignificant in form
validation code are not carried over into DHTML where they might serve
to cripple the code on slower systems?

<snip>
... . The entry could have additional notes mentioning ... <snip>As long as notes are made that with a NAME attribute that
either way works and that the shorthand is marginally
faster, its fine.
If you are satisfied with those conditions I will have a go at writing
those notes.
I notice that you didn't quote the modified 4.13, do I take
that as implying that you would prefer not to merge this with
the existing 4.13 question? (I quite liked that idea)


I think you are asking if I like the
idea of merging the two, and I do.


I was, and good! That is the way I will go, unless anyone objects.
Might be better in 4.39 where it already
discusses bracket notation though.
My page, linked to from 4.39, has an example of the shortcut form
accessor. At the time I didn't want to use that example but I needed a
common and recognisable accessor that wasn't too complex for the
example. But I don't think 4.39 (and the related document) is
appropriate for a discussion about forms and accessing them
specifically. Better if it sticks with the square bracket syntax in
general.
Either place, or even linked to a website about it. I just
think it should be explained (both ways, along with both ways
advantages/drawbacks) how to access a form and its elements in
the FAQ. And then let the script author decide whether they want
clarity or speed.


I didn't want to get into writing notes on form access because of all of
the other issues that equally deserve coverage. The alternative
accessors and their merits/drawbacks are relatively easy in comparison
with the ID/XHTML issues, but it looks like I am going to have to.

Richard.

[1] That only applies to colleges who would understand JavaScript
anyway. Colleges who understand only other languages have no right to
expect me to write:-

var divStyle = (div && div.style) ? div.style : div;

- instead of -

var disStyle = (div && div.style) || div;

-just because in their languages the result of the second expression
would be boolean not an object reference. Even though the code that
followed the second statement would be initially incomprehensible to a
programmer only familiar with, say, Java, as they would be surprised to
find the boolean result they expected being treated as an object.
Jul 20 '05 #16

P: n/a
"Dr John Stockton" <sp**@merlyn.demon.co.uk> wrote in message
news:R2**************@merlyn.demon.co.uk...
<snip>
ISTM, therefore, that it would be well to give the above as
Frm = document.forms['formName']
Ele = Frm.elements['elementName']
or similar, to give the clue that Frm can be used for
getting other elements.
In most cases when I want to reference multiple form elements (might
have to start calling them controls in the FAQ from now on) I assign a
reference to the form's elements collection to a local variable so that
it does not need to be re-resolved as a member of the form.
Re FAQ 4.13 link : IIRC, that was a good one; or, more globally,
the third link in 3.2, http://devedge.netscape.com/library/manuals/
2000/java script/1.3/reference/, is/was good - better than
the 1.5 version, provided that it is used with care.
That's a good point. I will try and keep the reference to the 1.3 doce
in somewhere.
I suspect that it may be worth-while using a links-checker on
the FAQ from time to time; those not found can be given a
temporary "where is it" mark.
Jim's scripts check the references when they build the page (and
apparently style them differently in the HTML version if not found). But
I will be (have been) verifying them anyway ( I have already found that
the second in 2.3 is apparently no longer there).
If the FAQ is getting a complete make-over, ISTM that it might
be worth classifying the contents of Sec. 4 by topics (which
wasn't necessary when it started).


Unfortunately it isn't that simple as reordering section 4 would throw
off all of the references to it in the archives (the anchors are
generated dynamically from the order in the XML) and on the whole I
think that sacrificing the usefulness of the archives is something I
don't want to do right now.

Given enough time it might be possible to re-do the scripts and XML
format to avoid that problem, but I should probably get this revision
complete first.

Richard.
Jul 20 '05 #17

P: n/a
On Tue, 20 Jan 2004 08:30:42 -0000, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote:
Unfortunately it isn't that simple as reordering section 4 would throw
off all of the references to it in the archives (the anchors are
generated dynamically from the order in the XML) and on the whole I
think that sacrificing the usefulness of the archives is something I
don't want to do right now.


This was a severe oversight on my part, in retrospect I should not
have used numbers, but named faq's for the quick answers when I took
over.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #18

P: n/a
JRS: In article <_9********************@comcast.com>, seen in
news:comp.lang.javascript, Randy Webb <hi************@aol.com> posted at
Mon, 19 Jan 2004 18:52:09 :-
Lasse Reichstein Nielsen wrote:
Randy Webb <hi************@aol.com> writes:

Now, do we recommend clarity, or speed?

In a FAQ: Clarity, without exception.
Speed at most gets a foot note.


Then why do we recommend +varName to convert to a number when
parseInt/parseFloat(varName) is more concise?


They can seem more concise only to those who do not know the meaning of
the word, as given by Oxford & Webster. They might be considered more
explicit.

It seems impossible to express an action more concisely than by a single
character; and + is easy to explain because the whole operand is a
standard number (or 0x<hex>) and there is no need to go into the
termination condition.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for 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.
Jul 20 '05 #19

P: n/a
Dr John Stockton wrote:
JRS: In article <_9********************@comcast.com>, seen in
news:comp.lang.javascript, Randy Webb <hi************@aol.com> posted at
Mon, 19 Jan 2004 18:52:09 :-
Lasse Reichstein Nielsen wrote:
Randy Webb <hi************@aol.com> writes:

Now, do we recommend clarity, or speed?
In a FAQ: Clarity, without exception.
Speed at most gets a foot note.
Then why do we recommend +varName to convert to a number when
parseInt/parseFloat(varName) is more concise?

They can seem more concise only to those who do not know the meaning of
the word, as given by Oxford & Webster. They might be considered more
explicit.


Point taken, and I will make note of it next time, to look up all words
that I use in the dictionary.

As for a definition, the dictionary I use defines explicit as:

1 a : fully revealed or expressed without vagueness, implication, or
ambiguity : leaving no question as to meaning or intent <explicit
instructions>

And you are indeed correct that its a more explicit word to use.
It seems impossible to express an action more concisely than by a single
character; and + is easy to explain because the whole operand is a
standard number (or 0x<hex>) and there is no need to go into the
termination condition.


Your argument is that +varName leaves less question as to meaning than
using Number(varName) does?

The plus sign has two uses in javascript, the Number function only has
one. Fewer uses means less confusion, less confusion leads to explicity.
--
Randy
Chance Favors The Prepared Mind

Jul 20 '05 #20

P: n/a
Randy Webb <hi************@aol.com> writes:
The plus sign has two uses in javascript, the Number function only has
one.
Actually Number has two uses. The first is a converter to the number
type (Number("42")), the other is as a constructor for number
*objects* (new Number(42)).

For the plus sign, I think you added the wrong way. "1" + "1" is not two,
but 11 (at least it is a lot more than two :). The uses I can remember:
Prefix sign/conversion
Infix number addition
Infix string concatentation
Optional sign on exponent of numbers in scientific notation (e.g. 864E+5)
In pre-increment ++
in post-increment ++
As repetition in regular expressions
Fewer uses means less confusion, less confusion leads to explicity.


I concur.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #21

P: n/a
JRS: In article <Lb********************@comcast.com>, seen in
news:comp.lang.javascript, Randy Webb <hi************@aol.com> posted at
Tue, 20 Jan 2004 18:30:34 :-
It seems impossible to express an action more concisely than by a single
character; and + is easy to explain because the whole operand is a
standard number (or 0x<hex>) and there is no need to go into the
termination condition.
Your argument is that +varName leaves less question as to meaning than
using Number(varName) does?


No. Perhaps you still have not looked up "concise".
The plus sign has two uses in javascript, the Number function only has
one. Fewer uses means less confusion, less confusion leads to explicity.


The second sentence, apart from having an unknown word, is generally
true. The plus sign has three distinct uses : binary, with at least one
string operand, is concatenation; binary, with two numbers, is addition;
unary is return a number.

But the binary operator + is very well known in arithmetic - it is
probably still taught in schools - and the unary is almost as well
known; the presence, in code, of a + that can only be a unary + should
cause no difficulty whatsoever in the second and subsequent occasions
when one is seen.

On the first occasion, there may be surprise; but, on the presumption
that it serves a purpose, there is only one reasonable interpretation :
that the result is a number.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for 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.
Jul 20 '05 #22

P: n/a
Richard Cornford wrote:
"Randy Webb" <hi************@aol.com> wrote in message
news:n8********************@comcast.com...
<snip>
I think we start with reliable. From there on we are clearly
into the realms of opinion, and we have:-
1. W3C HTML DOM conformance favouring the longer version
(though it is ambiguous whether it should allow the
shorthand of referring to the elements as named members
of the form, I still think it should).


Fair enough, even though I personally thing too much
weight/discussion is given to W3C, ECMAScript, or any
other "regulating body". <shrug>

I don't think we can get away from ECMA 262, its algorithms define what
is "correct" for the language. Not that there is much that can be done
if an interpreter is identified as objectively wrong. There are also
job/task specifications that vaguely call for coding to conform to
"applicable web standards" so there is some value in knowing what those
standards are, and their implications.


Arguing ECMA is the same as arguing form access. We can both argue until
Hades freezes over about it. We are both right and both wrong (in
different regards). While we are waiting for the freeze, we can even
argue whether Hades exists or not.

For the record, the FAQ should use the longhand notation. For more
reasons than speed, but shorthand will always beat it speed-wise. Agreed?
<--snip-->
Maybe the value in discussing and promoting fast implementation in
JavaScript is so that bad habits that are insignificant in form
validation code are not carried over into DHTML where they might serve
to cripple the code on slower systems?
Good point.
<snip>
... . The entry could have additional notes mentioning ...
<snip>
As long as notes are made that with a NAME attribute that
either way works and that the shorthand is marginally
faster, its fine.

If you are satisfied with those conditions I will have a go at writing
those notes.


See above :) But I do think the speed should be mentioned. If for no
other reason than completeness.
I notice that you didn't quote the modified 4.13, do I take
that as implying that you would prefer not to merge this with
the existing 4.13 question? (I quite liked that idea)


I think you are asking if I like the
idea of merging the two, and I do.

I was, and good! That is the way I will go, unless anyone objects.


No objections :)

--
Randy
Chance Favors The Prepared Mind

Jul 20 '05 #23

P: n/a
"Randy Webb" <hi************@aol.com> wrote in message
news:h4********************@comcast.com...
<snip>
For the record, the FAQ should use the longhand notation.
For more reasons than speed,
but shorthand will always beat it speed-wise. Agreed?
The mechanics of property accessor resolution mean that the shorthand
accessors will always be resolved quicker than the longer versions.

<snip>... But I do think the speed should be mentioned.
If for no other reason than completeness.


Completeness, an unfortunate paradox: the more complete the less chance
of finishing. :)

Yes I will mention the existence of the shorthand accessors and the
relative speeds of resolution. But I will also mention storing a form
(and/or elements collection) reference as a local variable for
efficiency when referencing multiple form controls.

I have been looking at the number formatting functions in 4.6 recently
but I will start working on a revised 4.13 shortly.

Incidentally, as 4.6 is going to be chanced to a more general number to
formatted string question and have a separate page of notes there will
be room for quite a few examples of number formatting functions. So if
anyone has any favourite useful number formatting functions they would
like to contribute I would appreciate seeing them.

Richard.
Jul 20 '05 #24

P: n/a
JRS: In article <bu*******************@news.demon.co.uk>, seen in
news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted at Thu, 22 Jan 2004 01:33:27 :-
Incidentally, as 4.6 is going to be chanced to a more general number to
formatted string question and have a separate page of notes there will
be room for quite a few examples of number formatting functions. So if
anyone has any favourite useful number formatting functions they would
like to contribute I would appreciate seeing them.


function LZ(x) {return(x<0||x>9?"":"0")+x}

function LZZ(x) {return(x<0||x>99?""+x:"0"+LZ(x))}

// Note that those *always* return strings, and the strings *always*
represent the right value, which *might* reduce undetected error.

function Prfx(Q, L, c) { var S = Q+"" // ??
// if (!c) var c = ' '
if (c.length>0) while (S.length<L) { S = c+S } ;
return S }

and anything else recommended in
http://www.merlyn.demon.co.uk/js-round.htm
http://www.merlyn.demon.co.uk/js-maths.htm

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for 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.
Jul 20 '05 #25

P: n/a
"Dr John Stockton" <sp**@merlyn.demon.co.uk> wrote in message
news:RU**************@merlyn.demon.co.uk...
<snip>
function LZ(x) {return(x<0||x>9?"":"0")+x}

function LZZ(x) {return(x<0||x>99?""+x:"0"+LZ(x))}

// Note that those *always* return strings, and the strings *always*
represent the right value, which *might* reduce undetected error.

function Prfx(Q, L, c) { var S = Q+"" // ??
// if (!c) var c = ' '
if (c.length>0) while (S.length<L) { S = c+S } ;
return S }


Thanks for those.

While I was looking at the handling of numbers for formatting I noticed
that IE 4 does not have isNaN and isFinite but it struck me that NaN and
Infinity would probably want special handling under some circumstances
(maybe not often) and I wondered whether it would be worth emulating
them for IE 4 (and maybe some others). These are the functions that I
thought might be practical for the task:-

if(typeof isNaN != 'function'){
isNaN = function(n){
n = (+n);
/* NaN does not equal itself and should be the only number
for witch the type-converting equality test returns
false. So return NOT the result of the comparison:
*/
return !(n == n);
};
}
if(typeof isFinite != 'function'){
/* isFinite requires isNaN */
isFinite = function(n){
/* If the number is NaN return false, else if it is not
within the number range it must be infinite so return
false, else return true:
*/
return (!isNaN(n = (+n))&&((n <= Number.MAX_VALUE)&&
(n >= Number.MIN_VALUE)));
};
}

Would you mind trying them on IE 4 and letting me no if there are any
problems with them.

Very few of the number formatting functions I have found are designed to
cope with the possibility that the number is in the range that would
normally be converted to a string in exponential format and I it
occurred to me that there might be some desire for methods that could
handle (or at least be aware of) that possibility.

To that end I was considering using the RegExp.exec method to split any
(non-NaN/Infinite) number up into its significant parts as one starting
point for more general formatting. The Regular expression that I have
been testing is:-

/^([+-])?(\d+)(\.(\d+))?([eE]([+-]?)(\d+))?$/

With the array returned from RegExp.exec being used as: Index 1 is the
leading sign (if any), index 2 is the digits in front of the decimal
point in the mantissa, index 4 the digits that follow the decimal point,
index 6 is the sign of the exponent (if any) and index 7 the digits of
the exponent. Is there a regular expression better suited to the task of
splitting a string representation of a number up into its component
parts?

Richard.
Jul 20 '05 #26

P: n/a
JRS: In article <bu*******************@news.demon.co.uk>, seen in
news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted at Fri, 23 Jan 2004 03:35:36 :-
"Dr John Stockton" <sp**@merlyn.demon.co.uk> wrote in message
news:RU**************@merlyn.demon.co.uk...
While I was looking at the handling of numbers for formatting I noticed
that IE 4 does not have isNaN and isFinite
My IE 4 does have them.

Small Flanagan says that isNaN is javascript 1.1 and isFinite is js 1.2;
and that both are ECMA-262. Also that IE4 & NS4 are js 1.2.

ISTM that the FAQ might list js versions for a few browsers, and that
answers in the FAQ might include js version needed, where known.

Scanning my site, I've used isNaN but not isFinite - ISTM that they do
not need emulating for FAQ purposes, because isNaN has appeared by NS3 &
IE4, isFinite by NS4 & IE3, and isFinite is not of much use. However,
one should consider other browsers of similar vintage.

but it struck me that NaN and
Infinity would probably want special handling under some circumstances
(maybe not often) and I wondered whether it would be worth emulating
them for IE 4 (and maybe some others). These are the functions that I
thought might be practical for the task:-
Would you mind trying them on IE 4 and letting me no if there are any
problems with them.
Renamed versions seem to do what they should.

Very few of the number formatting functions I have found are designed to
cope with the possibility that the number is in the range that would
normally be converted to a string in exponential format and I it
occurred to me that there might be some desire for methods that could
handle (or at least be aware of) that possibility.
My routines in js-round.htm are designed to *always* show the right
value, even if the number is unreasonable for the routine - RSVP if any
of those alleged to be good do fail here.

Where a value, possibly the accumulated US budget in cents, cannot be
represented in the designated width, then ISTM that the programmer
should choose whether to break width or change format.

Where a value cannot be represented in the designated format, then ISTM
that the programmer should choose whether to change format.

Having a library routine change the format should be considered as a
sort of non-fatal error message.

To that end I was considering using the RegExp.exec method to split any
(non-NaN/Infinite) number up into its significant parts as one starting
point for more general formatting.
You cannot do that; you can only use a RegExp on a String representation
of a Number.

If a String represents a Number, then it can also be Hex or Octal, and
might have a decimal point not surrounded by decimal digits.
The Regular expression that I have
been testing is:-

/^([+-])?(\d+)(\.(\d+))?([eE]([+-]?)(\d+))?$/

With the array returned from RegExp.exec being used as: Index 1 is the
leading sign (if any), index 2 is the digits in front of the decimal
point in the mantissa, index 4 the digits that follow the decimal point,
index 6 is the sign of the exponent (if any) and index 7 the digits of
the exponent. Is there a regular expression better suited to the task of
splitting a string representation of a number up into its component
parts?


There *might* be value in capturing the previous and following
characters if present; and/or a space in the sign position.

I do not see the need for this.

If a Number is to be decomposed to that extent, it should be done by
arithmetic.

X=+0.00087
Neg = X<0
Pos = X>0
Nun = X==0 ; Mant=Expo=0
if (!Nun) {
A = Math.abs(X)
Expo = Math.floor(Math.log(A)*Math.LOG10E)
Mant = A*Math.pow(10, -Expo) }
Z = [Neg, Nun, Pos, Mant, Expo]

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for 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.
Jul 20 '05 #27

P: n/a
On Fri, 23 Jan 2004 17:06:23 +0000, Dr John Stockton
<sp**@merlyn.demon.co.uk> wrote:
Small Flanagan says that isNaN is javascript 1.1 and isFinite is js 1.2;
and that both are ECMA-262. Also that IE4 & NS4 are js 1.2.

ISTM that the FAQ might list js versions for a few browsers, and that
answers in the FAQ might include js version needed, where known.


This is something where I would disagree with Flanagan, JavaScript 1.2
only has relevance to NN4 JavaScript 1.5 has relevance for other
browsers, but IE4 is certainly not JavaScript 1.2 it's JScript 3.0 -
or more likely it's JScript 5.6 as I can't really imagine many people
letting an unpatched windows system out onto the web, even if they
insist on keeping IE4.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #28

P: n/a
JRS: In article <40***************@news.cis.dfn.de>, seen in
news:comp.lang.javascript, Jim Ley <ji*@jibbering.com> posted at Sat, 24
Jan 2004 13:42:11 :-
On Fri, 23 Jan 2004 17:06:23 +0000, Dr John Stockton
<sp**@merlyn.demon.co.uk> wrote:
Small Flanagan says that isNaN is javascript 1.1 and isFinite is js 1.2;
and that both are ECMA-262. Also that IE4 & NS4 are js 1.2.

ISTM that the FAQ might list js versions for a few browsers, and that
answers in the FAQ might include js version needed, where known.


This is something where I would disagree with Flanagan, JavaScript 1.2
only has relevance to NN4 JavaScript 1.5 has relevance for other
browsers, but IE4 is certainly not JavaScript 1.2 it's JScript 3.0 -
or more likely it's JScript 5.6 as I can't really imagine many people
letting an unpatched windows system out onto the web, even if they
insist on keeping IE4.


All the more reason for putting it in the FAQ! You have later
information than Flanagan then did.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; Win98.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
Jul 20 '05 #29

P: n/a
On Sat, 24 Jan 2004 20:03:52 +0000, Dr John Stockton
<sp**@merlyn.demon.co.uk> wrote:
All the more reason for putting it in the FAQ! You have later
information than Flanagan then did.


No Flanagan was simply wrong, and falling into the common confusion of
giving implementations which emulate JavaScript, JavaScript's version
number based on sort of how similar the implementations are, I don't
think that's constructive.

All we can really say now is ECMAScript Ed.1 is pretty safe, otherwise
it's a right mess IMO. What versions are supported where is not
frequently asked.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #30

P: n/a
"Dr John Stockton" <sp**@merlyn.demon.co.uk> wrote in message
news:Nf**************@merlyn.demon.co.uk...
<snip>
While I was looking at the handling of numbers for formatting
I noticed that IE 4 does not have isNaN and isFinite
My IE 4 does have them.

Small Flanagan says that isNaN is javascript 1.1 and isFinite is
js 1.2; and that both are ECMA-262. Also that IE4 & NS4 are js 1.2.


The core language documentation from Netscape for JS 1.4 states that
isFinite was introduced in 1.3 rather than 1.2 and some JScript
documentation I have states that both were introduced in JScript 5.
Though the MSDN site says versions 1 and 3 respectively. I am not sure
if I trust any of them. But, as Jim pointed out, it is unlikely to be a
problem as JScript versions depend on a DLL and are likely to be updated
with security and OS patches and/or any later installation of any
Microsoft software that allows scripting (WSH, Office, etc).

I don't think I am going to worry about them any more.

<snip>
Very few of the number formatting functions I have found are
designed to cope with the possibility that the number is in
the range that would normally be converted to a string in

exponential format ...

My routines in js-round.htm are designed to *always* show the
right value, even if the number is unreasonable for the routine
- RSVP if any of those alleged to be good do fail here.
No, your number formatting functions don't behave stupidly with
exponential formatted numbers. I was searching c.l.j on google to see if
I could find any others that could feature in an expanded list of number
formatting functions and a recurring feature of the ones that I found
was that they tended to do stupid things with numbers of that type.
Which is partly why I am interested in seeing if anyone would like to
contribute alternatives, in the hope that they would be more robust.
Where a value, possibly the accumulated US budget in cents,
cannot be represented in the designated width, then ISTM that
the programmer should choose whether to break width or change
format. Where a value cannot be represented in the designated format,
then ISTM that the programmer should choose whether to change
format.
Because so many example number formatting functions that I found
disregarded the possibility of the string representation of those
numbers being in exponential format I thought it would be a good idea to
include one example that was explicitly interested in re-formatting
number strings in that format. To serve as a reminder that the
possibility existed.
To that end I was considering using the RegExp.exec method to
split any (non-NaN/Infinite) number up into its significant
parts as one starting point for more general formatting.


You cannot do that; you can only use a RegExp on a String
representation of a Number.

If a String represents a Number, then it can also be Hex or
Octal, and might have a decimal point not surrounded by decimal
digits.


My plan was to take the number and type-convert it to a string for use
with the RegExp. Which side steps the consideration of octal and hex
formats. I figured that the resulting string would be as precise a
representation of the number as was available and so the substrings
would contain exactly the information from the original, with no change
in their precision or the approximation of the original number.

That seemed well suited to some re-formatting problems, such as
turning -4.7e23 into -4.7x10<sup>23</sup> where to re-formatting would
only be string manipulation.

<snip>If a Number is to be decomposed to that extent, it should be
done by arithmetic.

X=+0.00087
Neg = X<0
Pos = X>0
Nun = X==0 ; Mant=Expo=0
if (!Nun) {
A = Math.abs(X)
Expo = Math.floor(Math.log(A)*Math.LOG10E)
Mant = A*Math.pow(10, -Expo) }
Z = [Neg, Nun, Pos, Mant, Expo]


What worried me about this approach was that taking a number that was
already within a range that required it to be expressed in exponential
format and then performing a sequence of mathematical operations on it
would suffer from additional approximations along the way. So even if
reversing the process always results in the original number any
presentation based on the isolated components of that number may distort
the original.

Richard.
Jul 20 '05 #31

This discussion thread is closed

Replies have been disabled for this discussion.