443,694 Members | 1,882 Online
Need help? Post your question and get tips & solutions from a community of 443,694 IT Pros & Developers. It's quick & easy.

# Howto validet that 2 > 12 from a form

 P: n/a 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 Jul 23 '05 #1
17 Replies

 P: n/a 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 Jul 23 '05 #2

 P: n/a 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 You probably want: "if (+a > +b)" rather than "if (a > b)". See the URL above for more information. -- Grant Wagner comp.lang.javascript FAQ - http://jibbering.com/faq Jul 23 '05 #3

 P: n/a 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 comp.lang.javascript FAQ - http://jibbering.com/faq Jul 23 '05 #4

 P: n/a In article <41***************@agricoreunited.com>, gw*****@agricoreunited.com enlightened us with... 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 Jul 23 '05 #5

 P: n/a kaeli wrote: Grant Wagner wrote: You probably want: "if (+a > +b)" rather than "if (a > b)". See the URL above for more information. 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? 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. Jul 23 '05 #6

 P: n/a kaeli wrote: In article <41***************@agricoreunited.com>, gw*****@agricoreunited.com enlightened us with... 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 comp.lang.javascript FAQ - http://jibbering.com/faq Jul 23 '05 #7

 P: n/a In article , 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 Jul 23 '05 #8

 P: n/a 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. Jul 23 '05 #9

 P: n/a 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. Jul 23 '05 #10

 P: n/a 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 Jul 23 '05 #12

 P: n/a 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. Jul 23 '05 #13

 P: n/a 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 Jul 23 '05 #14

 P: n/a JRS: In article <19****************@PointedEars.de>, dated Thu, 12 Aug 2004 23:16:07, seen in news:comp.lang.javascript, Thomas 'PointedEars' Lahn 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 -> Timo Salmi: Usenet Q&A. Web : about usage of News. No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News. Jul 23 '05 #15

 P: n/a 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 Jul 23 '05 #16

 P: n/a 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 Jul 23 '05 #17

 P: n/a JRS: In article <14****************@PointedEars.de>, dated Sat, 14 Aug 2004 05:18:50, seen in news:comp.lang.javascript, Thomas 'PointedEars' Lahn 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 FlanaganAlas, 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 © JL / RC : FAQ for news:comp.lang.javascript jscr maths, dates, sources. TP/BP/Delphi/jscr/&c, FAQ items, links. Jul 23 '05 #18

### This discussion thread is closed

Replies have been disabled for this discussion.