Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 2 12 LastLast
Results 1 to 15 of 24
  1. #1
    New Coder
    Join Date
    Feb 2013
    Posts
    38
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Validation for email no regexp

    Heres my function..

    Code:
    var email = "jon@email.com";
    function validateEmailAddress(em) {
    	var correct = true;
    	for (var i = 0; i < em.length; i++) {
    		var x = em.charAt(i);
    		if (i > 1) {
    			if (x === '@') {
    				if (x === '.') {
    					correct = true;
    				}
    				else {
    					correct = false;
    				}
    			}
    			else {
    				correct = false;
    			}
    		}
    		else {
    			correct = false;
    		}
    	return correct;
    	}
    }
    
    console.log("does this function really work? " + validateEmailAddress(email));
    I'm completely stuck on how to find @ and . in an email address. I thought I would be able to grab it when it looped through with a for statement followed by an if and then a nested if, but I seem to be completely wrong in my logic somewhere.
    Last edited by JonBMN; 02-27-2013 at 05:29 AM.

  • #2
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    27,191
    Thanks
    80
    Thanked 4,562 Times in 4,526 Posts
    indexOf( ).

    That is: email.indexOf("@") will tell you what character position the @ is at. And so on.

    There is also lastIndexOf( ).

    But this is, I hope you realize, pretty useless validation.

    Most people simply make sure that the @ sign is at character 1 or more and that the last period is at least 2 characters past the @ sign.

    But that doesn't prevent an email address of (example)
    Code:
        "..@.."
    Not to ask a pointed question, but... What happened to your phone number validation? You give up on it?
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #3
    New Coder
    Join Date
    Feb 2013
    Posts
    38
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Thank you old pedant; I appreciate the help. The phone number validation I actually finished and have moved on.

  • #4
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    27,191
    Thanks
    80
    Thanked 4,562 Times in 4,526 Posts
    Great work on the phone number! You know, you *could* post your result back here for critique before you instructor gets his/her hands on it, if you wanted.

    Email address validation is tougher. I don't really think you can do a decent job of it without a regular expression. Well, clearly that's not true: If worst came to worst you could duplicate all the stuff a regular expression evaluator does. Just that it might be almost that much work.

    There are SO MANY possible legal variations on an email address that it would be tough to make a good one without a regexp. Heck, it's tough to makes a *comprehensive* one even with a regexp.

    But I suppose you could do somelike this:
    Code:
    find at least two characters from the legal list, including period
    find the @ sign
    repeat 1 or more times:
        find at least two characters from the legal list, excluding period
        find a period
    end repeat
    find two to six letters
    That's not perfect, but good enough for 99% of purposes, surely.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #5
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Here's a comprehensive one with a regexp - it does check the lengths of the two parts of the email address first to make sure they don't exceed the allowed maximums. This will give you some idea of how complicated validating email addrresses is.

    Note that the following are valid email addresses even though they might not look like it:

    me@[127.0.0.1]
    =^.^=@kitteh.cat.com
    " "@example.com

    Code:
    validateEmail = function(email) {var e = (email+'@').split('@'); if (e[0].length > 255 || e[1].length > 63) return false; return !email.search(/^[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:(?:[^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff])|"[^\\\x80-\xff\n\015"]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015"]*)*")[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:\.[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff])|"[^\\\x80-\xff\n\015"]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015"]*)*")[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*)*@[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff])|\[(?:[^\\\x80-\xff\n\015\[\]]|\\[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:\.[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff])|\[(?:[^\\\x80-\xff\n\015\[\]]|\\[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*)*|(?:[^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff])|"[^\\\x80-\xff\n\015"]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015"]*)*")[^()<>@,;:".\\\[\]\x80-\xff\000-\010\012-\037]*(?:(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)|"[^\\\x80-\xff\n\015"]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015"]*)*")[^()<>@,;:".\\\[\]\x80-\xff\000-\010\012-\037]*)*<[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:@[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff])|\[(?:[^\\\x80-\xff\n\015\[\]]|\\[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:\.[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff])|\[(?:[^\\\x80-\xff\n\015\[\]]|\\[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*)*(?:,[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*@[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff])|\[(?:[^\\\x80-\xff\n\015\[\]]|\\[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:\.[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff])|\[(?:[^\\\x80-\xff\n\015\[\]]|\\[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*)*)*:[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*)?(?:[^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff])|"[^\\\x80-\xff\n\015"]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015"]*)*")[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:\.[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff])|"[^\\\x80-\xff\n\015"]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015"]*)*")[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*)*@[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff])|\[(?:[^\\\x80-\xff\n\015\[\]]|\\[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:\.[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\[\]\000-\037\x80-\xff])|\[(?:[^\\\x80-\xff\n\015\[\]]|\\[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*)*>)$/);}
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #6
    Supreme Master coder! Philip M's Avatar
    Join Date
    Jun 2002
    Location
    London, England
    Posts
    18,248
    Thanks
    203
    Thanked 2,556 Times in 2,534 Posts
    His thread title says "no regexp".

    But if you want a regex which will work in 99.99% of cases (it has never let me down), then

    if (!(/^([a-z0-9])([\w\.\-\+])+([a-z0-9])\@((\w)([\w\-]?)+\.)+([a-z]{2,4})$/i.test(email.value))) { /// returns true if invalid

    Pedants who want to allow for the domains "travel" and "museum" (which I have never encounted in practice) should change {2,4} to {2,6}.
    That still rejects "barreau" (French barristers).

    For myself I am not too concerned if addresses like

    me@[127.0.0.1]
    =^.^=@kitteh.cat.com
    " "@example.com

    are rejected. They are the sort of address often used by spammers and fraudsters. And I never have dealings with French barristers.

    As I have said before, validation does not in any way ensure that the entered address is correct. (@gmial.com). I think it is desirable to ask the user to enter his address and also confirm it by entering it a second time. This is often done, and reduces (but obviously does not eliminate) the chances of a typing error.
    Last edited by Philip M; 02-26-2013 at 10:29 AM.

    All the code given in this post has been tested and is intended to address the question asked.
    Unless stated otherwise it is not just a demonstration.

  • #7
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,448
    Thanks
    11
    Thanked 598 Times in 578 Posts
    Quote Originally Posted by Philip M View Post
    Pedants who want to allow for the domains "travel" and "museum" (which I have never encounted in practice) should change {2,4} to {2,6}.
    That still rejects "barreau" (French barristers).
    i'm afraid 6 chars won't cut it for very long.

    as of late last year,2000 ne TLDs have been proposed to be approved this year, and anyone can buy one, not just governments...

    also, these are ALL valid:
    Code:
    niceandsimple@example.com
    very.common@example.com
    a.little.lengthy.but.fine@dept.example.com
    disposable.style.email.with+symbol@example.com
    user@[IPv6:2001:db8:1ff::a0b:dbd0]
    "much.more unusual"@example.com
    "very.unusual.@.unusual.com"@example.com
    "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com
    postbox@com (top-level domains are valid hostnames)
    admin@mailserver1 (local domain name with no TLD)
    !#$%&'*+-/=?^_`{}|~@example.org
    "()<>[]:,;@\\\"!#$%&'*+-/=?^_`{}| ~.a"@example.org
    " "@example.org (space between the quotes)

    i think that "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com is my favorite; watch out for that 2nd @!
    Last edited by rnd me; 02-26-2013 at 11:28 AM.
    my site (updated 2014/10/20)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.3, IE11:9.2, IE9:2.7, IE10:2.6, FF:16.8, CH:47.5, SF:7.8, NON-MOUSE:37%

  • #8
    Supreme Master coder! Philip M's Avatar
    Join Date
    Jun 2002
    Location
    London, England
    Posts
    18,248
    Thanks
    203
    Thanked 2,556 Times in 2,534 Posts
    Yes, it is quite possible to invent outlandish email addresses. In fact my regex deals with several of them. At the end of the day, it is rather like disabling Javascript. People who choose "unusual" addresses do so at their own risk. No normal (I was tempted to say 'sane') person would choose an address
    like !#$%&'*+-/=?^_`{}|~@example.org, and if they did I think I would rather steer clear of them.

    Perhaps the solution is to simply check for an @ followed by a . and leave it at that, and make the user enter his address twice.
    It is surely the responsibility of the user to get his email address right - just like his postal address. There is little point in putting in huge effort to ensure that the email address is semantically valid when at the same time the biggest risk is that it is just plain wrong.

    Code:
    function validateForm() {
    var em = document.getElementById("email").value;
    var atpos = em.indexOf("@");
    var dotpos = em.lastIndexOf(".");
    
    if (atpos<1 || dotpos<atpos+2 || dotpos+2>=x.length)  {
    alert (em + " is not a valid e-mail address");
    document.getElementById("email").value = "";  // clear the field and refocus on it
    document.getElementById("email").focus();
    return false;
    }
    
    }
    I would forget user@[IPv6:2001:db8:1ff::a0b:dbd0]

    In any case, we all know that Javascript can be disabled, so it is essential to validate on the server as well.
    Last edited by Philip M; 02-26-2013 at 01:34 PM.

    All the code given in this post has been tested and is intended to address the question asked.
    Unless stated otherwise it is not just a demonstration.

  • #9
    New Coder
    Join Date
    Feb 2013
    Posts
    38
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Thank you everyone for posting in my topic. I will post the phone number validator once the project has been turned in and graded; I would not want to get a zero because the exact same thing is out on the web.

    But even though I can't use regexp doesn't mean I can't learn them! thank you everybody I will be sure to include it in my future coding projects if needed. I will be sure to post my finished email validator at the same time as well.

  • #10
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,448
    Thanks
    11
    Thanked 598 Times in 578 Posts
    you can also use html5, though you won't learn much from doing so:

    Code:
    <input type= email />
    Code:
    <input type=tel />
    my site (updated 2014/10/20)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.3, IE11:9.2, IE9:2.7, IE10:2.6, FF:16.8, CH:47.5, SF:7.8, NON-MOUSE:37%

  • #11
    Supreme Master coder! Philip M's Avatar
    Join Date
    Jun 2002
    Location
    London, England
    Posts
    18,248
    Thanks
    203
    Thanked 2,556 Times in 2,534 Posts
    Quote Originally Posted by rnd me View Post
    you can also use html5, though you won't learn much from doing so:

    Code:
    <input type= email />
    Code:
    <input type=tel />
    But you still have to provide a pattern to validate against!

    Code:
    <input type="email" pattern="[^ @]*@[^ @]*" value="">
    And (as so often) it does not work in IE9. That makes it useless to me.

    I don't really see this as a very useful feature. Although as I understand it, if your user is browsing with an iPhone and they arrive at a special email input, the iPhone will display a keyboard with the @ symbol provided on the primary screen.
    Last edited by Philip M; 02-26-2013 at 08:07 PM.

    All the code given in this post has been tested and is intended to address the question asked.
    Unless stated otherwise it is not just a demonstration.

  • #12
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by JonBMN View Post
    But even though I can't use regexp doesn't mean I can't learn them! thank you everybody I will be sure to include it in my future coding projects if needed. I will be sure to post my finished email validator at the same time as well.
    If you can't use a regexp then perhaps the safest email validation would be to check that the email address contains an @ not more than 255 characters from the start of the address and that there are not more than 63 characters following it. What comes before the @ can be almost anything and the email address can still be valid. The part afterward can only contain letters, numbers, - and . (with the latter two not being allowed at the start or end) if the part after the @ starts with [ then it must end with ]

    Note that email addresses don't need to contain a . for example me@localhost is a perfectly valid email address (but one that can only be used within a local network).
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #13
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by Philip M View Post
    But you still have to provide a pattern to validate against
    Surely the main point in providing those types is that browsers will implement a built in pattern to validate them against so that people writing web pages don't need to learn regular expressions to be able to use them Just because none of the browsers have implemented it yet doesn't mean that they are not going to if those tags survive into the HTML 5 standard.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #14
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,448
    Thanks
    11
    Thanked 598 Times in 578 Posts
    Quote Originally Posted by Philip M View Post
    I don't really see this as a very useful feature. Although as I understand it, if your user is browsing with an iPhone and they arrive at a special email input, the iPhone will display a keyboard with the @ symbol provided on the primary screen.
    pretty much any phone can also pull up the contact list and paste the info into the input when the person's list item is tapped. no more typos for them!


    In short, it's a super cheap way to improve the user experience of many forms for a wide and growing swath of users, without breaking anything else. It also makes it easy to style consistently (attrib selectors work in IE7 CSS). It's beneficial to A.T. to guide disabled users though often-confusing and repetitive delineralized forms, making your site more accessible. It can allow almost turnkey social network integration using common libraries. It compliments HTML5 validation to provide a more descriptive error message that "match pattern". Lastly, it opens the door to turn-key old-IE validation polyfills so you don't have to ask around on forums to try to find an email validation routine.

    I really can't think of a downside to any of that.


    not working in IE9 does not make it useless, it works just as well as <input type=text> in oldIE afaik; no harm, no foul.

    i'm really struggling with this one. i mean, if you are going to use "text" anyway, why not use "tel" or "email"?

    what about those attribs makes them useless to you?

    i can't think of any downside, especially not one that would negate the strong ROI of using modern semantic syntax.
    my site (updated 2014/10/20)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.3, IE11:9.2, IE9:2.7, IE10:2.6, FF:16.8, CH:47.5, SF:7.8, NON-MOUSE:37%

  • #15
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,448
    Thanks
    11
    Thanked 598 Times in 578 Posts
    Quote Originally Posted by felgall View Post
    Surely the main point in providing those types is that browsers will implement a built in pattern to validate them against so that people writing web pages don't need to learn regular expressions to be able to use them Just because none of the browsers have implemented it yet doesn't mean that they are not going to if those tags survive into the HTML 5 standard.
    i will bet everything i own that the <input> tags will make the HTML5 cut.

    several browsers DO support a lot of the new types already. The ipad is not going away anytime soon. I don't think Chrome or FF are holding their breath on the next HTML5 status update;

    the goal of the new types is three fold:
    1. semantics (accessibility, SEO, readability)
    2. integration (better UI than text, pre/auto/user-fill from elsewhere)
    3. validation (known uses have known patterns, no js client validation)


    see http://www.w3.org/TR/html5/forms.htm...te-(type=email) for info on the email input type, which has more special features than meet the eye.

    it also drops this little nugget:
    This requirement is a willful violation of RFC 5322, which defines a syntax for e-mail addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here.


    The following JavaScript- and Perl-compatible regular expression is an implementation of the above definition.

    Code:
    /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/

    anyway, i'm just saying that some browsers indeed have implemented many of the new type attribs already, and that it's about more than validation...
    my site (updated 2014/10/20)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.3, IE11:9.2, IE9:2.7, IE10:2.6, FF:16.8, CH:47.5, SF:7.8, NON-MOUSE:37%


  •  
    Page 1 of 2 12 LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •