• suscipere (unregistered) in reply to JuanCarlosII
    JuanCarlosII:
    Sorry, but this is probably the biggest non-WTF I've ever seen on this site.

    I think someone is clearly confusing "Not everyone runs JavaScript" with "No-one runs JavaScript".

    Where is this article is there any suggestion that there is not additional validation of data conducted on the server? Clearly the intention of this function (which admittedly has changed since it was named - possibly the only vague WTF in the article) is to tell when a user is attempting to enter an invalid character and provide immediate feedback to the user without requiring a round trip to the server. Last time I checked this is a good thing.

    There's plenty of WTFs out there to do with JavaScript, but simply using JS to provide additional functionality to a user is most definitely not one of them.

    Well, hold on there. This function appears to be invoked on keydown or keypress, that's a pretty good start at wtfery. Rolling on, this validation routine has the side quest of jumping the focus to another (allegedly "dec") field if the user types a period. This functionality, however, never happens, because the else if clause before it shorts it out.
    else if ((("0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZa" + "bcdefghijklmnopqrstuvwxyz.,-/?!$ ").indexOf(keychar) > -1)) return true;

    Input-time validation is mostly just annoying. The page should give clear indication of expected content, and validate at the execution step, rather than the input step.

    Ignoring these design choices, and playing in the crappy little sandbox we're stuck in (knowing nothing of the surrounding..."architecture"), I would still rewrite it:

    function validateUserKeyAndPossiblyJumpToDecimalField(myfield, e, dec){
      if(!e)e=window.event;
      var key=e&&(e.keyCode||e.which);
      var safeKeys=[null,0,8,9,13,27];
      for(var i=0;i<safeKeys.length;i++){
        if(key==safeKeys[i])return true;
      }
      var keychar=String.fromCharCode(key);
      if(/[0-9a-z,-/?!$]/i.test(keychar))return true;
      if(dec&&(keychar=="."))myfield.form.elements[dec].focus();
      return false;
    }
    </pre>I ...suscipere... you might write the same kind of crap the OP's lulz target writes, if you didn't find this WTFy enough.
    
  • secundum (unregistered) in reply to akatherder
    akatherder:
    Farmer Innes-D'en:
    TRWTF is that anybody assumes client-side Javascript to have done any validation for them. No, really. Page one, people, page one.

    Then make sure they have javascript.

    <form method="post" action="process.php">
    <input type="button" onclick="this.form.submit();">
    </form>
    
    No, dude.

    Obvious troll is obvious, but it's also wrong. default behavior on <input type="button" /> is submit.

  • incassum (unregistered) in reply to Callin
    Callin:
    NetBen:
    This is a WTF if this is THE only user input validation.

    This is NOT a WTF if this function is part of enhancing user experience.

    Both factors unknown, so useless article.

    This says it all.
    Not quite. It's also shit script, and buggy.

  • persto (unregistered) in reply to tetsu
    tetsu:
    TWTF is that there is a function named "numbersonly" that takes three parameters: a field, an event, and a number. Why it takes these three parameters is not obvious. It acts like a real-time input handler, which isn't necessary.

    It purports to return True or False depending on if the characters (or single input character, in this case) is a number. Instead, it changes the form and input behavior. The function is tied to the form, tied exclusively to that field, and afaik is called infinitely, because of that last 'else true' that lets you have no myfield or event but still return true as if the input is considered a 'number'.

    tl;dr It's a boolean utility function that changes the state. Changes the state in ways it never suggests it would. Like allowing alphas and question marks.

    Man, finally someone that gets it! This. is TRWTF.

  • persto (unregistered) in reply to dkf
    dkf:
    NetBen:
    This is a WTF if this is THE only user input validation.

    This is NOT a WTF if this function is part of enhancing user experience.

    Both factors unknown, so useless article.

    Oh, it has plenty of WTF!s in it even without knowing whether it is the only validation.

    My favourite that I've seen so far is that bit with checking if it's processing decimal and, if so, comparing to see if the key was a period. When that character is a member of set of chars checked for previously. Thankfully, the test wouldn't lead to an observable outcome anyway, since it's just choosing whether to return false, or to instead return false. Vital decision, that…

    (Yes, there's a focus change in there. Anyone want to bet which element would be focused on at that point?)

    And this is the other part. Well done. I was starting to lose faith in Alex's readership.

  • persto (unregistered) in reply to voyou
    voyou:
    tetsu:
    It purports to return True or False depending on if the characters... It's a boolean utility function that changes the state.

    No, it's not, it's an event handler, and as such it returns true or false depending on whether or not the event should be handled further. It has a badly chosen name, sure (both because the name doesn't make clear that it is an event handler, and because it suggests it limits input to numbers, rather than a broader range of characters). But reading the function, it's intent is perfectly clear. The fact that it doesn't do what you incorrectly think it should do, is your problem, not a problem in the code.

    Not quite. It's a function that is called by an event handler, or so we assume by the event treatment. It is itself, however, NOT an event handler, or we wouldn't have 'myField' and 'dec' parameters (and 'e' would be Fist!!1!).

    Ergo, there is a place further up the stack that could appropriately workflow the disparate actions occurring in this validation routine.

    tetsu's point stands.

  • (cs) in reply to Anonymous
    Anonymous:
    People are defending this as reasonable client-side validation. But as far as I'm concerned, any validation that occurs on every keypress is fundamentally wrong. Why process every single key when you could just process the whole thing on submit? Unless it specifically needs to process every key press I would say that this is definitely a WTF. Not a major one, but a WTF nonetheless.
    It's not quite as simple as that. Why? Well, because you don't know what the response to a validation failure is. Sure, if it's popping up an obnoxious dialog box then you don't want to do that sort of thing very often, but if it's using a subtle effect like underlining the affected characters or changing the background of the entry box, then validating on key is exactly right. The rule I learned was to save the “stop everything and howl at the user” responses to validation failure until you get to the point where it's either that or insert bad data in the database. This is because it's sometimes a good thing for the user to temporarily put bad data in a field while they're working; they plan to go back and change it, but forcing them to do it when they're there to start out with is rude (and encourages them to just use paper the whole time). After all, they probably know more about their job in practice than you do.

    But if you want to keep on appearing to be an idiot, by all means, stick to your silly preconceptions on validation. Just never read a book by a real GUI designer or you'll realize just how silly you've been all along…

  • Jonathan Collins (unregistered)

    I think my favorite part is actually this:

      else
        return true;
    
  • Stephen (unregistered) in reply to Adam

    I've had this in New Zealand too - I emailed the site about the usability issues and they fixed it!

    Now it deletes the character as soon as you type it - at least I had javascript enabled :)

  • Patrick (unregistered) in reply to JuanCarlosII
    JuanCarlosII:
    Sorry, but this is probably the biggest non-WTF I've ever seen on this site.

    I think someone is clearly confusing "Not everyone runs JavaScript" with "No-one runs JavaScript".

    Where is this article is there any suggestion that there is not additional validation of data conducted on the server? Clearly the intention of this function (which admittedly has changed since it was named - possibly the only vague WTF in the article) is to tell when a user is attempting to enter an invalid character and provide immediate feedback to the user without requiring a round trip to the server. Last time I checked this is a good thing.

    There's plenty of WTFs out there to do with JavaScript, but simply using JS to provide additional functionality to a user is most definitely not one of them.

    My thought exactly. In fact, it could be made faster with char codes.

    else if(keychar>0x1F && keychar<0x7B) return true;

    (of course add another condition for the characters in that range you still don't want)

  • Patrick (unregistered)

    OK. So originally it was an event handler for a number-only field. That's obvious, by the event handling code inside it. Also, since javascript does support calling a function without providing all the parameters, it still can.

    First modification: It can also be called from another event handler so you can say "yo, handle decimal points too. Here are my parameters". This "handling" jumps it to a second input, presumably one that doesn't handle decimal points. Just like entering a license key in four textboxes that jump from one to the next.

    Second modification: Control keys. So you can copy, paste, tab or submit. Might be useful, but that leaves it open to pasting ANYTHING. Though, this could be taken care of in on-submit validation.

    Third modification: Takes capital letters. Hexadecimal? Just the alphabet for an alphanumeric code?

    Fourth modification: OK, so now it takes all letters and can support full sentence structure (except apostrophe). WTF? Are you not using the numbers thing at all anymore? Because you just broke it.

  • persto (unregistered) in reply to Patrick
    Patrick:
    JuanCarlosII:
    Sorry, but this is probably the biggest non-WTF I've ever seen on this site.

    I think someone is clearly confusing "Not everyone runs JavaScript" with "No-one runs JavaScript".

    Where is this article is there any suggestion that there is not additional validation of data conducted on the server? Clearly the intention of this function (which admittedly has changed since it was named - possibly the only vague WTF in the article) is to tell when a user is attempting to enter an invalid character and provide immediate feedback to the user without requiring a round trip to the server. Last time I checked this is a good thing.

    There's plenty of WTFs out there to do with JavaScript, but simply using JS to provide additional functionality to a user is most definitely not one of them.

    My thought exactly. In fact, it could be made faster with char codes.

    else if(keychar>0x1F && keychar<0x7B) return true;

    (of course add another condition for the characters in that range you still don't want)

    Except that now you have to check e.shiftKey as well, since the keydown codes for numbers are the same as their symbol counterparts.

    Way to fail, bucko.

  • persto (unregistered) in reply to Patrick
    Patrick:
    OK. So originally it was an event handler for a number-only field. That's obvious, by the event handling code inside it. Also, since javascript does support calling a function without providing all the parameters, it still can.

    First modification: It can also be called from another event handler so you can say "yo, handle decimal points too. Here are my parameters". This "handling" jumps it to a second input, presumably one that doesn't handle decimal points. Just like entering a license key in four textboxes that jump from one to the next.

    Second modification: Control keys. So you can copy, paste, tab or submit. Might be useful, but that leaves it open to pasting ANYTHING. Though, this could be taken care of in on-submit validation.

    Third modification: Takes capital letters. Hexadecimal? Just the alphabet for an alphanumeric code?

    Fourth modification: OK, so now it takes all letters and can support full sentence structure (except apostrophe). WTF? Are you not using the numbers thing at all anymore? Because you just broke it.

    No. Order of parameters precludes your first premise. Do over, show your work.

  • feugiat (unregistered) in reply to Stephen
    Stephen:
    I've had this in New Zealand too - I emailed the site about the usability issues and they fixed it!

    Now it deletes the character as soon as you type it - at least I had javascript enabled :)

    Good point! ALEX, FFS, fix the line 31 "Object expected" JS error in the brand .js referencing an attribute ('src') that doesn't exist! sheesh, all u oblivious ____ety ____s using firefox and other hidey-hidey browsers maybe oughta start paying attention to "those obnoxious js errors" and FIXING THEM instead of ignoring 'em, hey?

  • zefciu (unregistered)

    The reason for which it's called 'numbersonly' is that the guy took a ready-made function limiting input to numbers and expanded the character list not even bothering to correct the comments.

  • Kovensky (unregistered)

    I thought about sending this piece of work from my college website's login form as a WTF but ended up not due to being too lazy to translate / annotate the code, but I guess I won't need to after all... :)

    Interestingly, this breaks using 'tab' for switching fields on Firefox but not on IE6.

    <input class='form_campo' name='cpdaluno' onkeypress='return ValidaEntrada(event, 0)' maxlength='7' size='7' height='10'>
    
    function ValidaEntrada(e, tip) {
    	var tecla = "";
    	if(document.all) // Internet Explorer
    		var tecla = event.keyCode;
    	else
    		var tecla = e.which;
    	if (tecla=="") tecla = e.which; // colocado em funcao do Browser FireFox
    	if (tip != 1) {
    		if (tecla > 47 && tecla < 58) // numeros de 0 a 9
    			return true;
    		else {
    			if (tecla != 8) // backspace
    				return false;
    			else
    				return true;
    		}
    	} else {
    		if ((tecla > 47 && tecla < 58) || (tecla == 84) || (tecla == 116)) // numeros de 0 a 9
    			return true;
    		else {
    			if (tecla != 8) // backspace
    				return false;
    			else
    				return true;
    		}
    	}
    }
    
  • LoneTech (unregistered) in reply to Anonymous

    "any validation that occurs on every keypress is fundamentally wrong." I disagree. For instance, I recently filled in a secret message for the "verified by VISA" program. The message has to be 20-30 characters and has very strict restrictions on what characters may be included. For this case, I'd find it entirely reasonable to use the maxlength attribute so the browser would stop me from writing too long messages. Instead they opted to make a 10 lines long text entry field with a form submission that complained on mismatching length. And erased the entire message, if any invalid character was found. Way to make the user have to do computer work (counting letters) AND guess at what the requirements are.

  • Anonymous (unregistered) in reply to dkf
    dkf:
    Anonymous:
    People are defending this as reasonable client-side validation. But as far as I'm concerned, any validation that occurs on every keypress is fundamentally wrong. Why process every single key when you could just process the whole thing on submit? Unless it specifically needs to process every key press I would say that this is definitely a WTF. Not a major one, but a WTF nonetheless.
    It's not quite as simple as that. Why? Well, because you don't know what the response to a validation failure is. Sure, if it's popping up an obnoxious dialog box then you don't want to do that sort of thing very often, but if it's using a subtle effect like underlining the affected characters or changing the background of the entry box, then validating on key is exactly right. The rule I learned was to save the “stop everything and howl at the user” responses to validation failure until you get to the point where it's either that or insert bad data in the database. This is because it's sometimes a good thing for the user to temporarily put bad data in a field while they're working; they plan to go back and change it, but forcing them to do it when they're there to start out with is rude (and encourages them to just use paper the whole time). After all, they probably know more about their job in practice than you do.

    But if you want to keep on appearing to be an idiot, by all means, stick to your silly preconceptions on validation. Just never read a book by a real GUI designer or you'll realize just how silly you've been all along…

    I really don't see why you had to turn your remark into a personal attack. Are you so insecure that you need to attack anyone who doesn't agree with your method of input validation? Are you really that pathetic? And FYI, I stand behind everything I said. If you are wasting valuable cycles on validating every keystroke then the benefit of this must outweigh the cost. For a trivial little "thank you" note on some webpage, the benefit is practically zero (after all, who needs dynamic validation for a freeform thank you note). Now run along to class you angst-ridden little turd.

  • Anonymous (unregistered) in reply to LoneTech
    LoneTech:
    "any validation that occurs on every keypress is fundamentally wrong." I disagree. For instance, I recently filled in a secret message for the "verified by VISA" program. The message has to be 20-30 characters and has very strict restrictions on what characters may be included. For this case, I'd find it entirely reasonable to use the maxlength attribute so the browser would stop me from writing too long messages. Instead they opted to make a 10 lines long text entry field with a form submission that complained on mismatching length. And erased the entire message, if any invalid character was found. Way to make the user have to do computer work (counting letters) AND guess at what the requirements are.
    Learn to read:
    Anonymous:
    Unless it specifically needs to process every key press I would say that this is definitely a WTF.
  • the beholder (unregistered) in reply to Patrick
    Patrick:
    OK. So originally it was an event handler for a number-only field. That's obvious, by the event handling code inside it. Also, since javascript does support calling a function without providing all the parameters, it still can.

    First modification: It can also be called from another event handler so you can say "yo, handle decimal points too. Here are my parameters". This "handling" jumps it to a second input, presumably one that doesn't handle decimal points. Just like entering a license key in four textboxes that jump from one to the next.

    Second modification: Control keys. So you can copy, paste, tab or submit. Might be useful, but that leaves it open to pasting ANYTHING. Though, this could be taken care of in on-submit validation.

    Third modification: Takes capital letters. Hexadecimal? Just the alphabet for an alphanumeric code?

    Fourth modification: OK, so now it takes all letters and can support full sentence structure (except apostrophe). WTF? Are you not using the numbers thing at all anymore? Because you just broke it.

    How come a Thank-you note field's starting requirements were to accept only numbers? Were they marketing robots at first?

  • JavaScriptDisabler (unregistered) in reply to persto

    TRWTF is that the function does not return FILE_NOT_FOUND under any circumstances.

  • (cs) in reply to the beholder
    the beholder:
    Patrick:
    OK. So originally it was an event handler for a number-only field.
    How come a Thank-you note field's starting requirements were to accept only numbers? Were they marketing robots at first?
    No, Patrick was saying the routine was originally for a number-only field. i.e. not for the Thank-you note field.

    It then got copied and extended.

  • Andrei (unregistered)

    ಠ_ಠ

  • undefined (unregistered) in reply to JuanCarlosII

    Using JavaScript for anything at all is wrong because someone might not have it enabled.

    And using HTML for anything at all is wrong because someone might use telnet instead of web-browser.

  • undefined (unregistered)

    Actually javascript:while(1)alert("Thank you for enabling javascript") was the reason that i use Opera as my browser.

  • (cs) in reply to undefined
    undefined:
    And using HTML for anything at all is wrong because someone might use telnet instead of web-browser.

    Actually, the first time I ever implemented a web browser, I used a telnet connection to grab the data from the server and pass it to my rendering engine. Telnet will deliver HTML just fine. In fact, a lot of the early web servers I connected to even responded to telnet option negotiation, leading me to believe the people writing homebrew servers were probably starting from a telnet server in the first place. :)

  • ClaudeSuck.de (unregistered)

    The RWTF is

    // decimal point jump else if (dec && (keychar == ".")) { myfield.form.elements[dec].focus(); return false; }

    when I enter a dot I am focussed to another field then the one I currently am.

  • Dude (unregistered)

    Why this got posted in the first place is the biggest WTF ever.

    The guy was obviously just trying to make his application more user friendly by adding a quick and simple input sanitation on the front-end. I can't believe you're nitpicking on a small snippet of JavaScript that actually works and fills its purpose.

  • (cs) in reply to JuanCarlosII
    JuanCarlosII:
    Carl:
    The function is horribly mis-named, but the author doesn't seem to think that's a very big deal. So the WTF is using Javascript to perform input validation? Lame.
    You don't seem to understand. Using JavaScript for anything at all is wrong because someone might not have it enabled.

    Repeat: everything you ever thought you knew about progressive enhancement is wrong.

    Dude, seriously? If you actually need to validate something, that need does not vanish just because the client has no JavaScript. If you don't need to validate it, then why write a script in the first place?

    Hopefully, the user input gui was provided by the JavaScript runtime itself, in which case this is not a WTF. But that isn't the case, is it?

  • (cs) in reply to Complete Moron
    Complete Moron:
    This code looks like complete shiite and is trying to do too much in a poorly written method. TRWTF is seeing actual value in deploying it, and that value as being worth more than the headache of maintaining this type of junk.

    EXACTLY!

  • veniam (unregistered) in reply to Zylon
    Zylon:
    Mark Bowytz:
    Now, before bashing the function for it's a curious name...
    Bob the Angry Flower would like a word with you, Mark.

    It's just one letter.. Sheesh!

  • Vladas (unregistered) in reply to JuanCarlosII
    You don't seem to understand. Using JavaScript for anything at all is wrong because someone might not have it enabled.

    Repeat: everything you ever thought you knew about progressive enhancement is wrong.

    It seems I forgot the place in my browser(s) where i can disable JS.:)

  • anon (unregistered)

    why not use server side programming through a series of form submits to validate the form inputs? this is javascript agnostic and works quite well, esp if the page is lightweight (which form pages should be anyway).

Leave a comment on “Thank You for Enabling JavaScript!”

Log In or post as a guest

Replying to comment #:

« Return to Article