Howto validet that 2 > 12 from a form

[KS]

I got 2 inputs in a form where I want check if start > end. Seems like it
just compare the first number when I got this code in javascript
"if(document.all.start > document.all.end)"
How do i solve this so it compare 2 > 10 as, is two bigger than ten, and
not, is two bigger than one.
Thanx in advance

[kaeli]

In article <41********@news.broadpark.no>, ka*****@hotmail.com enlightened us
with...

I got 2 inputs in a form where I want check if start > end. Seems like it
just compare the first number when I got this code in javascript
"if(document.all.start > document.all.end)"
How do i solve this so it compare 2 > 10 as, is two bigger than ten, and
not, is two bigger than one.
Thanx in advance

It's comparing them as strings, which is what the value always is. 2 > 1.

Use parseInt.

And get away from IE proprietary document.all syntax, which is AFAIU even
deprecated in IE6.

if (parseInt(document.forms["formname"].elements["start"].value,10) >
parseInt(document.forms["formname"].elements["end"].value,10) >

Note that this will fail if the value is not a number (null, blank, mix, etc)
- you should add a check for that in production code. Look at the isNaN
function and comparing to NaN.

--
--
~kaeli~
Acupuncture is a jab well done.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Grant Wagner]

KS wrote:

I got 2 inputs in a form where I want check if start > end. Seems like it
just compare the first number when I got this code in javascript
"if(document.all.start > document.all.end)"
How do i solve this so it compare 2 > 10 as, is two bigger than ten, and
not, is two bigger than one.
Thanx in advance

<url: http://jibbering.com/faq/#FAQ4_21 />

You probably want: "if (+a > +b)" rather than "if (a > b)". See the URL above
for more information.

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

[Grant Wagner]

kaeli wrote:

And get away from IE proprietary document.all syntax, which is AFAIU even
deprecated in IE6.

I'd re-word that as "experienced JavaScript authors in this newsgroup (and
hopefully elsewhere) recommend against using the document.all collection to
access any DOM element".

This is because unfortunately Microsoft's document does not show document.all as
being deprecated.

What's even more unfortunate it does not even show that document.all is _not
recommended_ and suggest authors use the available DOM1 methods
(getElementById(), getElementsByTagName(), etc) instead.

And with Gecko-based browsers now _supporting_ document.all (in addition to Opera
which has for some time), it is unlikely we will see the end of document.all in
our lifetimes.

To paraphrase a favorite quote of mine: In 20 million years when the continental
drift creates an earth unrecognizable and even cockroaches can't stand it
anymore, you can be sure that there remain Web servers buried far beneath the
ocean with scripts containing "document.all" thanks to Microsoft, Opera and now
Mozilla (insert insult against the Mozilla decision-makers here).

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

[kaeli]

In article <41***************@agricoreunited.com>, gw*****@agricoreunited.com
enlightened us with...

<url: http://jibbering.com/faq/#FAQ4_21 />

You probably want: "if (+a > +b)" rather than "if (a > b)". See the URL above
for more information.

Grant,

Is there any downside to using the plus sign? I always use parseInt, but then
you have to put in code to make sure it doesn't get pukey with NaN.
How does the plus sign react to non-numbers or alphanumerics?

--
--
~kaeli~
A bicycle can't stand on its own because it is two tired.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Richard Cornford]

kaeli wrote:

Grant Wagner wrote:

<url: http://jibbering.com/faq/#FAQ4_21 />

You probably want: "if (+a > +b)" rather than "if (a > b)". See the
URL above for more information.

<snip> Is there any downside to using the plus sign? I always use parseInt,
but then you have to put in code to make sure it doesn't get pukey
with NaN.
How does the plus sign react to non-numbers or alphanumerics?

<URL: http://jibbering.com/faq/faq_notes/type_convert.html >

There is at least one downside to every method of converting a string
into a number. Unary plus forces a type-conversion so it uses the type
conversion rules. It's oddities are: an empty string becomes numeric
zero, (positive) "0x..." formats are interpreted as Hex (but it never
interprets anything as Octal) and "123e45" style strings are interpreted
into numbers like javascript numeric literals. Alphabetical (and most
alphanumeric) strings become NaN, as do - undefined - and all objects.
null and boolean false become zero, true becomes one.

It has been proposed that string input from users that is expected to be
a number should be verified using regular expressions prior to any
type-conversion or use of parseInt/float. And once that has been done an
accepted string should be safely amenable to whichever method best
suites the context. Unary plus (type-converting in general) is
considerably faster than parseInt/Float.

Richard.

[Grant Wagner]

kaeli wrote:

In article <41***************@agricoreunited.com>, gw*****@agricoreunited.com
enlightened us with...

<url: http://jibbering.com/faq/#FAQ4_21 />

You probably want: "if (+a > +b)" rather than "if (a > b)". See the URL above
for more information.

Grant,

Is there any downside to using the plus sign? I always use parseInt, but then
you have to put in code to make sure it doesn't get pukey with NaN.
How does the plus sign react to non-numbers or alphanumerics?

It converts anything that can't be converted into NaN, which is never less than,
greater than, or equal to, another Number or even NaN itself.

var a = 1, b = 'a';
alert(+a > +b); // false
alert(+a < +b); // false
alert(+a == +b); // false
var a = 'a', b = 'b';
alert(+a > +b); // false
alert(+a < +b); // false
alert(+a == +b); // false

This is the same behavior as parseInt() on the client-side implementations I've
tested.

I prefer the unary operator because we work with a server-side implementation of
JavaScript where parseInt() on an unparsable String returns 0, not NaN (actually I
seem to recall reading documentation that stated that it returns 0 due to some
underlying HP-UX dependancy, on Solaris and Windows NT, the product behaves
correctly). This may not seem like a significant problem, but it can be when you
need to distinguish between an actual unparsable value (NaN) and a zero (0).
Number() would give me the same effect as the unary operator but with worse
performance.

Just to be consistent and generate less errors, I've started to use the unary
operator on the client as well.

And it's easy enough to turn NaN into 0 if required:

var i = 'a';
i = +i || 0;

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

[kaeli]

In article <cf*******************@news.demon.co.uk>,
Ri*****@litotes.demon.co.uk enlightened us with...

It has been proposed that string input from users that is expected to be
a number should be verified using regular expressions prior to any
type-conversion or use of parseInt/float. And once that has been done an
accepted string should be safely amenable to whichever method best
suites the context. Unary plus (type-converting in general) is
considerably faster than parseInt/Float.

Good to know. I already check format with reg exp before parseInt anyway.
I think I'll be using this in the future for my textbox stuff. Neat trick.
Thanks to you and Grant.

--
--
~kaeli~
All I ask is the chance to prove that money cannot make me
happy.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Thomas 'PointedEars' Lahn]

Grant Wagner wrote:

kaeli wrote:

And get away from IE proprietary document.all syntax, which is AFAIU even
deprecated in IE6.
I'd re-word that as "experienced JavaScript authors in this newsgroup (and
hopefully elsewhere) recommend against using the document.all collection
to access any DOM element".

Oh, so I am not an "experienced JavaScript author" IYHO, thank you.
Be very careful with generalization.
This is because unfortunately Microsoft's document does not show
document.all as being deprecated.

And support for users with browsers who don't know anything else should be
dropped IYHO? Remember out NN4 discussion lately[1]? I did not recommend
against trying with document.layers although NN4 is clearly deprecated by
Netscape, just wanted to have it given the least possible priority.
PointedEars
___________
[1] BTW, you really want to refrain from using the HTML composer.

[Thomas 'PointedEars' Lahn]

Grant Wagner wrote:

kaeli wrote:

And get away from IE proprietary document.all syntax, which is AFAIU even
deprecated in IE6.
I'd re-word that as "experienced JavaScript authors in this newsgroup (and
hopefully elsewhere) recommend against using the document.all collection
to access any DOM element".

Oh, so I am not an "experienced JavaScript author" IYHO, thank you.
Be very careful with generalization.
This is because unfortunately Microsoft's document does not show
document.all as being deprecated.

And support for users with browsers who don't know anything else should be
dropped IYHO? Remember our NN4 discussion lately[1]? I did not recommend
against trying with document.layers although NN4 is clearly deprecated by
Netscape, just wanted to have it given the least possible priority.
PointedEars
___________
[1] BTW, you really want to refrain from using the HTML composer.

[Grant Wagner]

Thomas 'PointedEars' Lahn wrote:

Grant Wagner wrote:

kaeli wrote:

And get away from IE proprietary document.all syntax, which is AFAIU even
deprecated in IE6.
I'd re-word that as "experienced JavaScript authors in this newsgroup (and
hopefully elsewhere) recommend against using the document.all collection
to access any DOM element".

Oh, so I am not an "experienced JavaScript author" IYHO, thank you.
Be very careful with generalization.

Again, you are being intentionally obtuse. It is entirely obvious one can not
argue against using document.all to access a DOM element where that is the only
mechanism by which to access DOM elements.

I understand now I need to have written: "experienced JavaScript authors in this
newsgroup (and hopefully elsewhere) recommend against using the document.all
collection to access any DOM element where an alternate W3C compliant mechanism
to achieve the same result is available within the user agent environment
because using document.all is a proprietary way of doing this and it would be
better to use a more standards-compliant way for future compatibility and this
is only as long and run on as it is because Thomas Lahn enjoys being
intentionally obtuse and refuses to fill in the unspoken but obvious fact that
one can not reasonably argue against not using document.all when it is the only
mechanism available to the author of the client-side JavaScript running in the
particular user agent and I hope this explains it clearly enough this time".

Hopefully the above is much clearer to you, although with sufficient motivation,
I am sure you can take exception with most of what I have written above, and
given your past behaviour, you appear particularly motivated to take exception
with pretty much anything anyone says.

This is because unfortunately Microsoft's document does not show
document.all as being deprecated.

And support for users with browsers who don't know anything else should be
dropped IYHO? Remember our NN4 discussion lately[1]? I did not recommend
against trying with document.layers although NN4 is clearly deprecated by
Netscape, just wanted to have it given the least possible priority.

Deprecation of the collection does not mean that support for the collection
would be _removed_ from either past, current or even future versions. To quote
from dictionary.com:

dep·re·cate:
1. To express disapproval of; deplore.
2. To belittle; depreciate.

And m-w.com:

dep·re·cate:
1 a archaic : to pray against (as an evil) b : to seek to avert <deprecate the
wrath ... of the Roman people -- Tobias Smollett>
2 : to express disapproval of
3 a : PLAY DOWN : make little of <speaks five languages ... but deprecates this
facility -- Time> b : BELITTLE, DISPARAGE <the most reluctantly admired and
least easily deprecated of ... novelists -- New Yorker>

And whatis.com:

deprecate:
In computer programming, a deprecated language entity is one that is tolerated
or supported but not recommended. For example, a number of elements and
attributes are deprecated in HTML 4.0, meaning that other means of accomplishing
the task are preferred. Deprecated features may become obsolete in future
versions of HTML, though browsers that support the features may continue to
support them.
Note: "to express disapproval of", "supported but not recommended", "other means
of accomplishing the task are preferred".

Microsoft can formally mark document.all as "deprecated" (they have not done
so). This would mean that they "express disapproval of", "support but do not
recommend" and "other means of accomplishing the task are preferred". The
"deprecated feature (document.all) may become obsolete (ie - be removed) in
future versions of their DOM" (to paraphrase the whatis.com definition).

On the other hand, document.layers has _not_ been marked as deprecated, support
for it has been _removed_ from versions of Netscape greater than version 4.xx.
The only way document.layers could be considered "deprecated" would be if it
were still supported in Netscape versions 6 and greater but could potentially
disappear in future versions. Also, use of document.layers is the _only_ means
for controlling any aspect of the Netscape 4.xx DOM as it related to dynamic
content and as such, if you wish to support Netscape 4.xx, support for
document.layers can not be avoided.

document.layers has been obsoleted, not deprecated.
[1] BTW, you really want to refrain from using the HTML composer.

Thank you for the advice. It will be given the consideration it deserves, a
decision will be reached based on that consideration and action will be taken
based on that decision.
Since this is my last reply to these meaningless debates you seem to enjoy
engaging in, I'll get a few things off my chest:

You take exception to a THREE LINE signature. Not only do you take exception to
it, you include 9 lines of USELESS advice about how to prevent a 3 line
signature (if you had checked the headers before providing a link to an Outlook
Express specific solution you would have known it would be of no help). How hard
is it to simply ignore the '--' and two lines that appear after it? Does it not
take significantly more effort to tilt at usenet windmills then to simply ignore
the things that do not fit into your usenet world view? How many resources are
you saving by sending 9 lines of advice about how to avoid a 2 line attribution
to everyone who uses an attribution you disapprove of? Your behaviour, if it
were not so completely insane, would be laughable.

You take exception to the software I chose to use to post to this usenet group
although it generates posts which are in compliance with usenet standards - else
the posts would not appear or propagate. The software I choose to use affects
you in NO WAY WHATSOEVER. It seems self-evident that if '--' appears near the
bottom of a usenet post and the first thing on the next line is a person's name,
everything thereafter is a signature. If your software does not indicate it as
such, perhaps you could use your brain and adjust your reading patterns to stop
reading at the point where you realize the rest of the post is a signature. This
is much the same way it is necessary for me to mentally skip the first couple
paragraphs of your posts where you typical rant about attributions and such.

You are intentially obtuse and demand _every_ _single_ _concept_ _and_ _idea_
_be_ _spelled_ _out_ _down_ _to_ _the_ _last_ _l_e_t_t_e_r_. Anything that goes
unwritten or assumed is an invitation for you to deliberately misunderstand and
find fault with.

Quite frankly, it's exhausting. And although you are an intelligent person, and
have many useful ideas to contribute, you have worn me out with your constant
and deliberate misunderstandings and attempts to change others' behaviour in
ways that simply do not matter.

I wanted to avoid being kill filed so as to avoid duplicate replies to questions
(since you would no longer be able to see my reply pointing a poster to the FAQ
for example), but now I simply no longer care.

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

[Thomas 'PointedEars' Lahn]

Grant Wagner wrote:

Thomas 'PointedEars' Lahn wrote:

Grant Wagner wrote:

> kaeli wrote:
>> And get away from IE proprietary document.all syntax, which is AFAIU
>> even deprecated in IE6.
>
> I'd re-word that as "experienced JavaScript authors in this newsgroup
> (and hopefully elsewhere) recommend against using the document.all
> collection to access any DOM element".

Oh, so I am not an "experienced JavaScript author" IYHO, thank you.
Be very careful with generalization.

Again, you are being intentionally obtuse. [...]

Again, you have wasted my time. The last time.
PointedEars

[KS]

Nice job folks, finally some people with some skills, and the extra info is
great:)
Any books or websites that help people to choose the right code which is not
proprietary and
is more "clean" javascript. The way is should be written. There are many
ways to get the same result, but it might not be the best way.

[Thomas 'PointedEars' Lahn]

KS wrote:

Any books or websites that help people to choose the right code which is
not proprietary and is more "clean" javascript. The way is should be
written.
Most books about the topic (both language and DOM) are badly written,
inaccurate and obsolete. Some even do not explain that it is necessary to
test for available DOM features; they just recommend using them, ignoring
the script errors.

Using a proprietary object model rather that a standards compliant one is
nothing more "clean" JavaScript (which is now but a programming language)
than drinking tea rather than coffee -- both contain caffeine, both can be
drunken. At first it must *work* with the target UAs, *then* optimization
can and should be done. The result would be a mixed usage of DOMs, while
testing for each features that is used before it is actually used. This
would include libraries to contain methods for repeated tasks, to ease the
scripting of the frontend and make the calling source code more readable.
There are many ways to get the same result, but it might not be the best
way.

The best way is when it works for as many users as possible/reasonable and
provides graceful degradation for the others. Enforcing standards support
and leaving the users whose software is not recent enough alone with the
problems is not a viable approach; they will just switch site and you have
gained nothing but lost something. Instead, by exploring possibilities of
the preferred object model(s), the user should be convinced that using
software that supports Web standards provides a better experience of the
same Web site than using one that does not support them or does support
them not as complete as the other one does.
PointedEars

[Dr John Stockton]

JRS: In article <19****************@PointedEars.de>, dated Thu, 12 Aug
2004 23:16:07, seen in news:comp.lang.javascript, Thomas 'PointedEars'
Lahn <Po*********@web.de> posted :

Grant Wagner wrote:

Thomas 'PointedEars' Lahn wrote:

Grant Wagner wrote:
> kaeli wrote:
>> And get away from IE proprietary document.all syntax, which is AFAIU
>> even deprecated in IE6.
>
> I'd re-word that as "experienced JavaScript authors in this newsgroup
> (and hopefully elsewhere) recommend against using the document.all
> collection to access any DOM element".

Oh, so I am not an "experienced JavaScript author" IYHO, thank you.
Be very careful with generalization.

Again, you are being intentionally obtuse. [...]

Again, you have wasted my time. The last time.

Your attitude here, reminiscent of that of the Geheime Staatspolizei, is
what wastes time here, since it forces us to correct your brutally
rigorous interpretation of elderly recommendations.

Heil Thomas!

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME ©
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[Robert]

Any books or websites that help people to choose the right code which is not
proprietary and is more "clean" javascript.

javascript: The Definitive Guide by David Flanagan

Robert

[Thomas 'PointedEars' Lahn]

Robert wrote:

Any books or websites that help people to choose the right code which is
not proprietary and is more "clean" javascript.

javascript: The Definitive Guide by David Flanagan

Alas, recent examples here have shown that is belongs to the "bad books"
category.
PointedEars

[Dr John Stockton]

JRS: In article <14****************@PointedEars.de>, dated Sat, 14 Aug
2004 05:18:50, seen in news:comp.lang.javascript, Thomas 'PointedEars'
Lahn <Po*********@web.de> posted :

Robert wrote:

Any books or websites that help people to choose the right code which is
not proprietary and is more "clean" javascript.

javascript: The Definitive Guide by David Flanagan

Alas, recent examples here have shown that is belongs to the "bad books"
category.

That is not a constructive response; it does nothing to help KS.

IIRC, it has generally been agreed that all other known books are
considerably worse than Flanagan.

No book should be expected to be perfect.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> JL / RC : 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.