Disable Drop-box Based On Users Selection

**Michael Winter** · Jul 20 '05, 01:39 PM

Re: Disable Drop-box Based On Users Selection

On 18 Jan 2004 08:01:11 -0800, Blnukem <blnukem@hotmai l.com> wrote:
[color=blue]
> 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>Untitl ed Document</title>
> <meta http-equiv="Content-Type" content="text/html;
> charset=iso-8859-1">
> </head>
>
> <body bgcolor="#FFFFF F" text="#000000">
>
> <script>[/color]

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

<script type="text/javascript">
[color=blue]
> function DisableMondayDr opdown(bool)
> {
> if(document.Mon day.Hours == "Closed"){[/color]

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.
[color=blue]
> document.Monday .Hours1.disable d=bool;
> document.Monday .Hours2.disable d=bool;
> }
> }
> </script>[/color]

I certainly recommend that you enclose all attribute values in quotes.
[color=blue]
> <form name=Monday onChange="Disab leMondayDropdow n(true)">[/color]

The FORM element doesn't have an onchange intrinsic event. However, SELECT
elements do, and that's where you want to place the attribute.
[color=blue]
> <select name=Hours>
> <option value=2>2
> <option value=3>3
> <option value=4>4
> <option value=5>5
> <option value=Closed>Cl osed
> </select>[/color]

<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 toggleMondayDro pdown() {
// 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.elem ents['Hours'].value);

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

var state;

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

if that makes the expression any clearer.
*/

mondayForm.elem ents['Hours1'].disabled = state;
mondayForm.elem ents['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.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

**Jarmo** · Jul 20 '05, 01:39 PM

Re: Disable Drop-box Based On Users Selection

"Blnukem" <blnukem@hotmai l.com> wrote in message
news:25ea61f9.0 401180801.2f9f0 1aa@posting.goo gle.com...[color=blue]
> 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>Untitl ed Document</title>
> <meta http-equiv="Content-Type" content="text/html;
> charset=iso-8859-1">
> </head>
>
> <body bgcolor="#FFFFF F" text="#000000">
>
> <script>
> function DisableMondayDr opdown(bool)
> {
> if(document.Mon day.Hours == "Closed"){
> document.Monday .Hours1.disable d=bool;
> document.Monday .Hours2.disable d=bool;
> }
> }
> </script>
>
> <form name=Monday onChange="Disab leMondayDropdow n(true)">
> <select name=Hours>
> <option value=2>2
> <option value=3>3
> <option value=4>4
> <option value=5>5
> <option value=Closed>Cl osed
> </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[/color]

Minor changes:

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

function CheckMondayDrop down()
{
//alert("In change handler");
document.Monday .Hours1.disable d=(document.Mon day.Hours.value == "Closed");
document.Monday .Hours2.disable d=(document.Mon day.Hours.value == "Closed");
}
</script>

<form name=Monday>
<select name=Hours onChange="Check MondayDropdown( )">
<option value=2>2
<option value=3>3
<option value=4>4
<option value=5>5
<option value=Closed>Cl osed
</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.

**Randy Webb** · Jul 20 '05, 01:39 PM

Re: Disable Drop-box Based On Users Selection

Michael Winter wrote:
[color=blue]
> On 18 Jan 2004 08:01:11 -0800, Blnukem <blnukem@hotmai l.com> wrote:
>[/color]

<--snip-->
[color=blue][color=green]
>> {
>> if(document.Mon day.Hours == "Closed"){[/color]
>
>
> 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.[/color]

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)"[color=blue]
>[/color]
</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-->

[color=blue]
> [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. :)[/color]

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.formNa me...... when named forms are present was flawed.
[color=blue]
> 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).[/color]

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.formNa me.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

**Lasse Reichstein Nielsen** · Jul 20 '05, 01:39 PM

Re: Disable Drop-box Based On Users Selection

Randy Webb <hikksnotathome @aol.com> writes:
[color=blue]
> But, to say that its "better" than the other, when used with a name
> attribute, is plain wrong.[/color]

I like to think of "following the W3C DOM specification" as being better
than not. But yes, "better" is always subjective.
[color=blue]
> 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:[/color]

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.
[color=blue]
> 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.formNa me.elementName[/color]

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 - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

**Richard Cornford** · Jul 20 '05, 01:40 PM

Re: Disable Drop-box Based On Users Selection

"Randy Webb" <hikksnotathome @aol.com> wrote in message
news:pumdndV43I 2sbZfd4p2dnA@co mcast.com...
<snip>[color=blue]
>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.[/color]

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).
[color=blue]
>But, to say that its "better" than the other, when used
>with a name attribute, is plain wrong.[/color]

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>[color=blue]
>... 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.[/color]

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>[color=blue]
><FA ... Y>
>Q. How do I acces a form element?
>A. If the elements have an ID, then use the forms collection:
>document.for ms[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.for ms['formName'].elements['elementName']
>or:
>document.formN ame.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.[/color]

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.for ms['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.selectedInde x'].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.

**Randy Webb** · Jul 20 '05, 01:40 PM

Re: Disable Drop-box Based On Users Selection

Richard Cornford wrote:
[color=blue]
> "Randy Webb" <hikksnotathome @aol.com> wrote in message
> news:pumdndV43I 2sbZfd4p2dnA@co mcast.com...[color=green]
>>But, to say that its "better" than the other, when used
>>with a name attribute, is plain wrong.[/color]
>
>
> 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.[/color]

Clarity is not always the #1 issue. A lot has been said in the last few
years about speed.
[color=blue]
> 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.[/color]
[color=blue]
> 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.[/color]

I agree, I know you have a ton of work on your hands as it is.

[color=blue]
> 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>[/color]

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

**Richard Cornford** · Jul 20 '05, 01:40 PM

Re: Disable Drop-box Based On Users Selection

"Randy Webb" <hikksnotathome @aol.com> wrote in message
news:QYOdnZR5ho MFHJbd4p2dnA@co mcast.com...
<snip>[color=blue][color=green]
>>document.form s['myform'].elements['myEl']
>>
>>- style of accessor for the clarity it brings to the source code.[/color]
>
>Clarity is not always the #1 issue. A lot has been said in
>the last few years about speed.[/color]

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".
[color=blue][color=green]
>> <draft>
>> 4.nn How do I access a form element?
>> Named form elements may be referred to as named ...[/color][/color]
^^^^^^^^^^^^^^^ ^^^^
That should have read "named forms".

<snip>[color=blue]
>... . It didn't surprise me that shorthand
>was faster though, to be honest.[/color]

Nor me.

<snip>[color=blue]
>And if it turns out that longhand wins,
>I will start recommending it.[/color]

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>[color=blue]
>Now, do we recommend clarity, or speed?[/color]

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)
[color=blue]
>Personally, I prefer speed over any gain in clarity. If I need
>clarity, I can comment it :)[/color]

Richard.

**Dr John Stockton** · Jul 20 '05, 01:41 PM

Re: Disable Drop-box Based On Users Selection

JRS: In article <bufo70$4g1$1$8 300dec7@news.de mon.co.uk>, seen in
news:comp.lang. javascript, Richard Cornford
<Richard@litote s.demon.co.uk> posted at Mon, 19 Jan 2004 04:59:12 :-[color=blue]
>
>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.[/color]

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.demo n.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demo n.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demo n.co.uk/batfiles.htm> - also batprogs.htm.

**Dr John Stockton** · Jul 20 '05, 01:41 PM

Re: Disable Drop-box Based On Users Selection

JRS: In article <QYOdnZR5hoMFHJ bd4p2dnA@comcas t.com>, seen in
news:comp.lang. javascript, Randy Webb <hikksnotathome @aol.com> posted at
Mon, 19 Jan 2004 02:03:55 :-[color=blue]
>
>Personally, I prefer speed over any gain in clarity. If I need clarity,
>I can comment it :)[/color]

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.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

**Lasse Reichstein Nielsen** · Jul 20 '05, 01:41 PM

Re: Disable Drop-box Based On Users Selection

Randy Webb <hikksnotathome @aol.com> writes:
[color=blue]
> Now, do we recommend clarity, or speed?[/color]

In a FAQ: Clarity, without exception.
Speed at most gets a foot note.
[color=blue]
> Personally, I prefer speed over any gain in clarity. If I need
> clarity, I can comment it :)[/color]

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

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

**Randy Webb** · Jul 20 '05, 01:42 PM

Re: Disable Drop-box Based On Users Selection

Lasse Reichstein Nielsen wrote:[color=blue]
> Randy Webb <hikksnotathome @aol.com> writes:
>
>[color=green]
>>Now, do we recommend clarity, or speed?[/color]
>
>
> In a FAQ: Clarity, without exception.
> Speed at most gets a foot note.[/color]

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

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

And yes, + is the preferred/recommended way.

Which is it? Clarity or Speed?
[color=blue]
>[color=green]
>>Personally, I prefer speed over any gain in clarity. If I need
>>clarity, I can comment it :)[/color]
>
>
> In your own code, you are free to do as you prefer. :)[/color]

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

--
Randy

**Lasse Reichstein Nielsen** · Jul 20 '05, 01:42 PM

Re: Disable Drop-box Based On Users Selection

Randy Webb <hikksnotathome @aol.com> writes:
[color=blue]
> Then why do we recommend +varName to convert to a number when
> parseInt/parseFloat(varN ame) is more concise?[/color]

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.
[color=blue]
> http://www.jibbering.com/faq/#FAQ4_21
>
> And yes, + is the preferred/recommended way.
>
> Which is it? Clarity or Speed?[/color]

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 - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

**Randy Webb** · Jul 20 '05, 01:42 PM

Re: Disable Drop-box Based On Users Selection

Richard Cornford wrote:
[color=blue]
> "Randy Webb" <hikksnotathome @aol.com> wrote in message
> news:QYOdnZR5ho MFHJbd4p2dnA@co mcast.com...
> <snip>
>[/color]

<--snip-->
[color=blue]
>
> I think we start with reliable. From there on we are clearly into the
> realms of opinion, and we have:-[/color]
[color=blue]
> 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).[/color]

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

[color=blue]
> 2. Clarity in source code, favouring the longer version.[/color]

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" ???
[color=blue]
>
> 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.[/color]

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).
[color=blue]
> 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).[/color]

As long as notes are made that with a NAME attribute that either way
works and that the shorthand is marginally faster, its fine.
[color=blue]
> 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)[/color]

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

**Randy Webb** · Jul 20 '05, 01:42 PM

Re: Disable Drop-box Based On Users Selection

Lasse Reichstein Nielsen wrote:
[color=blue]
> Randy Webb <hikksnotathome @aol.com> writes:
>
>[color=green]
>>Then why do we recommend +varName to convert to a number when
>>parseInt/parseFloat(varN ame) is more concise?[/color]
>
>
> 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.[/color]

Very true.
[color=blue]
> 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.[/color]

Slower yet more concise. Which is exactly my point.
[color=blue]
>[color=green]
>>http://www.jibbering.com/faq/#FAQ4_21
>>
>>And yes, + is the preferred/recommended way.
>>
>>Which is it? Clarity or Speed?[/color]
>
>
> 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.[/color]

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

Disable Drop-box Based On Users Selection

Disable Drop-box Based On Users Selection

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment