Re: Disable Drop-box Based On Users Selection
"Randy Webb" <hikksnotathome @aol.com> wrote in message
news:n8ednWgETM McDJHdRVn-hQ@comcast.com. ..
<snip>[color=blue][color=green]
>>I think we start with reliable. From there on we are clearly
>>into the realms of opinion, and we have:-[/color]
>[color=green]
>> 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]
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.
[color=blue][color=green]
>>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.[/color]
Incidentally, for clarity I usually wrap unary + operations in
parenthesise.
[color=blue]
>Now, we are all saying "No, faster isn't better, clarity is" ???[/color]
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>[color=blue]
>In reality, none of the speed matters.[/color]
I don't think I would consider it good style to write inefficient code
without some other definite justification for doing so. But the
comprehensibili ty for collages[1] of the resulting code would be one
justification, so long as the result wasn't ridiculously inefficient.
[color=blue]
>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.[/color]
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.
[color=blue]
>But thats beside the point (Or not at least
>until you get into real heavy dHTML apps).[/color]
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>[color=blue][color=green]
>>... . The entry could have additional notes mentioning ...[/color][/color]
<snip>[color=blue]
>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]
If you are satisfied with those conditions I will have a go at writing
those notes.
[color=blue][color=green]
>>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.[/color]
I was, and good! That is the way I will go, unless anyone objects.
[color=blue]
>Might be better in 4.39 where it already
>discusses bracket notation though.[/color]
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.
[color=blue]
>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.[/color]
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 incomprehensibl e 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.
"Randy Webb" <hikksnotathome @aol.com> wrote in message
news:n8ednWgETM McDJHdRVn-hQ@comcast.com. ..
<snip>[color=blue][color=green]
>>I think we start with reliable. From there on we are clearly
>>into the realms of opinion, and we have:-[/color]
>[color=green]
>> 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]
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.
[color=blue][color=green]
>>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.[/color]
Incidentally, for clarity I usually wrap unary + operations in
parenthesise.
[color=blue]
>Now, we are all saying "No, faster isn't better, clarity is" ???[/color]
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>[color=blue]
>In reality, none of the speed matters.[/color]
I don't think I would consider it good style to write inefficient code
without some other definite justification for doing so. But the
comprehensibili ty for collages[1] of the resulting code would be one
justification, so long as the result wasn't ridiculously inefficient.
[color=blue]
>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.[/color]
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.
[color=blue]
>But thats beside the point (Or not at least
>until you get into real heavy dHTML apps).[/color]
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>[color=blue][color=green]
>>... . The entry could have additional notes mentioning ...[/color][/color]
<snip>[color=blue]
>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]
If you are satisfied with those conditions I will have a go at writing
those notes.
[color=blue][color=green]
>>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.[/color]
I was, and good! That is the way I will go, unless anyone objects.
[color=blue]
>Might be better in 4.39 where it already
>discusses bracket notation though.[/color]
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.
[color=blue]
>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.[/color]
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 incomprehensibl e 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.
Comment