Shipping details information validation in form - javascript

I am using required attribute to check the pattern on my form which get's the user's shipping info etc. I am running into 2 problems now. The required attribute does''t work in Safari or old IE. Also in the address pattern, if there is a "." lets say instead of North, user types in "N.". It comes up as invalid pattern. Is it better to use javascript to validate it? Also what other attributes can I use within my HTML to validate it because I believe pattern doesn't require user to have javascript enabled.
Here is the HTML part of my code in my form:
<input type="text" name="first_name" required pattern="[a-zA-Z]{1,}" size="30"/>
<input type="text" name="last_name" required pattern="[a-zA-Z]{1,}" size="30"/>
<input type="text" name="address1" required pattern="[a-zA-Z0-9 ]{1,}" size="30"/>
<input type="text" name="address2" pattern="[a-zA-Z0-9 ]{1,}" size="30"/>
<input type="text" name="city" required pattern="[a-zA-Z]{1,}" size="30"/>
<input type="text" name="zip" required pattern="[a-zA-Z0-9]{1,}" size="30"/>
<input type="email" name="email" required size="30" value=""/>
<input type="text" name="telephone" required pattern="[0-9]{9,}" size="30"/>
<input type="submit" id="checkout" name="checkout" class="button" value="Checkout" />

You should use javascript for checking what's inside or simply tell the user you're requiring him to type "North" instead of "N.". Users don't really mind those restrictions. For what regards the required attribute: use javascript aswell

Validating names/email/addreses using javascript's [a-zA-Z] (or \w) is a Bad Idea ™
You are making some pretty limiting assumptions about a valid users name (all tough, even Unicode can not represent everybody's name..).
Have a look (for example) here: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
For example, what about a chinese/arabic/russion/etc woman's last name who married an american (within your target-region) (think even bi-di text..).
Also, an input type 'email' is (as you have found out) new in html5. You can provide a fall-back (shim/polyfill/creation of your own) to validate the email. However.. validating email was already HARD to do and that has become worse (if not impossible without requiring frequent updates to the routine) now with all the (new) internationalized (top level) domain-names (for which the list is still growing). Knowing this, ultimately leads to the notion that even a shim/polyfill (external library) is going to have a hard time to correctly validate valid email-addresses.
Finally (since you also want to cater to Canada as you told in the chat), addresses:
what about: Côte Saint Luc, Quebec, Canada (just an example)?
Am I serious?
Yes, Depending on what you are coding for (region/audience/level of importance).
If you are fine with it, and understand the (very real possible) problems, then everything is fine.. as long as you are not using this for some legit government tax-system etc ... Or an airline booking website... etc.
However... the solution is actually simple:
be relaxed about what you accept (client-side validation shouldn't be necessary for such fields),
use Unicode for all localized fields (that includes email, and address and name) (accept that you can not solve the problem that Unicode can not represent everybody's name, but in the future that is fixed, for example China will not accept those characters anymore for newborns since (I think) 2012),
Just make sure there's no malignant code on the server-side!
Edit: you must sanitize every input on the server-side anyway (never trust on javascript for that), meaning that you also should have the code/routines to handle input that your server-side script deemed invalid (something you could communicate to the user using ajax etc. and optionally provide a fallback (full page-refresh) when javascript is disabled).
Having all this in place, kind of provides you with the 'bonus-feature' that the cross-browser issues you are running into are no longer your problem, you can/should use the new features as icing on the cake: are required values empty or not, does the email address contain an '#', do the strings contain illegal 'Control Codes'/illegal/reserved characters, etc? These features are relatively easy and reliable to shim (just an example: http://html5please.com/#polyfill) if you should want fallback-mechanisms!
Do NOT forget these 'rules' (where relevant) when handling/passing/storing this data (you wouldn't be the first to accidentally stuff your Unicode data in a database in a localized transcoded code-page)!
Hope this helps!

Related

Disable 'Recently Entered Values' Dropdown For <input> Fields [duplicate]

This question's answers are a community effort. Edit existing answers to improve this post. It is not currently accepting new answers or interactions.
I have been running into issues with the chrome autofill behavior on several forms.
The fields in the form all have very common and accurate names, such as "email", "name", or "password", and they also have autocomplete="off" set.
The autocomplete flag has successfully disabled the autocomplete behavior, where a dropdown of values appear as you start typing, but has not changed the values that Chrome auto-populates the fields as.
This behavior would be ok except that chrome is filling the inputs incorrectly, for example filling the phone input with an email address. Customers have complained about this, so it's verified to be happening in multiple cases, and not as some some sort of result to something that I've done locally on my machine.
The only current solution I can think of is to dynamically generate custom input names and then extract the values on the backend, but this seems like a pretty hacky way around this issue. Are there any tags or quirks that change the autofill behavior that could be used to fix this?
Apr 2022: autocomplete="off" still does not work in Chrome, and I don't believe it ever has after looking through the Chromium bugs related to the issue (maybe only for password fields). I see issues reported in 2014 that were closed as "WontFix", and issues still open and under discussion [1][2]. From what I gather the Chromium team doesn't believe there is a valid use case for autocomplete="off".
Overall, I still believe that neither of the extreme strategies ("always honor autocomplete=off" and "never honor autocomplete=off") are good.
https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c66
They are under the impression that websites won't use this correctly and have decided not to apply it, suggesting the following advice:
In cases where you want to disable autofill, our suggestion is to
utilize the autocomplete attribute to give semantic meaning to your
fields. If we encounter an autocomplete attribute that we don't
recognize, we won't try and fill it.
As an example, if you have an address input field in your CRM tool
that you don't want Chrome to Autofill, you can give it semantic
meaning that makes sense relative to what you're asking for: e.g.
autocomplete="new-user-street-address". If Chrome encounters that, it
won't try and autofill the field.
https://bugs.chromium.org/p/chromium/issues/detail?id=587466#c10
Although this "suggestion" currently works for me it may not always hold true and it looks like the team is running experiments, meaning the autocomplete functionality could change in new releases.
It's silly that we have to resort to this, but the only sure way is to try and confuse the browser as much as possible:
Name your inputs without leaking any information to the browser, i.e. id="field1" instead of id="country".
Set autocomplete="do-not-autofill", basically use any value that won't let the browser recognize it as an autofillable field.
Jan 2021: autocomplete="off" does work as expected now (tested on Chrome 88 macOS).
For this to work be sure to have your input tag within a Form tag
Sept 2020: autocomplete="chrome-off" disables Chrome autofill.
Original answer, 2015:
For new Chrome versions you can just put autocomplete="new-password" in your password field and that's it. I've checked it, works fine.
Got that tip from Chrome developer in this discussion:
https://bugs.chromium.org/p/chromium/issues/detail?id=370363#c7
P.S. Note that Chrome will attempt to infer autofill behavior from name, id and any text content it can get surrounding the field including labels and arbitrary text nodes. If there is a autocomplete token like street-address in context, Chrome will autofill that as such. The heuristic can be quite confusing as it sometimes only trigger if there are additional fields in the form, or not if there are too few fields in the form. Also note that autocomplete="no" will appear to work but autocomplete="off" will not for historical reasons. autocomplete="no" is you telling the browser that this field should be auto completed as a field called "no". If you generate unique random autocomplete names you disable auto complete.
If your users have visited bad forms their autofill information may be corrupt. Having them manually go in and fix their autofill information in Chrome may be a necessary action from them to take.
I've just found that if you have a remembered username and password for a site, the current version of Chrome will autofill your username/email address into the field before any type=password field. It does not care what the field is called - just assumes the field before password is going to be your username.
Old Solution
Just use <form autocomplete="off"> and it prevents the password prefilling as well as any kind of heuristic filling of fields based on assumptions a browser may make (which are often wrong). As opposed to using <input autocomplete="off"> which seems to be pretty much ignored by the password autofill (in Chrome that is, Firefox does obey it).
Updated Solution
Chrome now ignores <form autocomplete="off">. Therefore my original workaround (which I had deleted) is now all the rage.
Simply create a couple of fields and make them hidden with "display:none". Example:
<!-- fake fields are a workaround for chrome autofill getting the wrong fields -->
<input style="display: none" type="text" name="fakeusernameremembered" />
<input style="display: none" type="password" name="fakepasswordremembered" />
Then put your real fields underneath.
Remember to add the comment or other people on your team will wonder what you are doing!
Update March 2016
Just tested with latest Chrome - all good. This is a fairly old answer now but I want to just mention that our team has been using it for years now on dozens of projects. It still works great despite a few comments below. There are no problems with accessibility because the fields are display:none meaning they don't get focus. As I mentioned you need to put them before your real fields.
If you are using javascript to modify your form, there is an extra trick you will need. Show the fake fields while you are manipulating the form and then hide them again a millisecond later.
Example code using jQuery (assuming you give your fake fields a class):
$(".fake-autofill-fields").show();
// some DOM manipulation/ajax here
window.setTimeout(function () {
$(".fake-autofill-fields").hide();
}, 1);
Update July 2018
My solution no longer works so well since Chrome's anti-usability experts have been hard at work. But they've thrown us a bone in the form of:
<input type="password" name="whatever" autocomplete="new-password" />
This works and mostly solves the problem.
However, it does not work when you don't have a password field but only an email address. That can also be difficult to get it to stop going yellow and prefilling. The fake fields solution can be used to fix this.
In fact you sometimes need to drop in two lots of fake fields, and try them in different places. For example, I already had fake fields at the beginning of my form, but Chrome recently started prefilling my 'Email' field again - so then I doubled down and put in more fake fields just before the 'Email' field, and that fixed it. Removing either the first or second lot of the fields reverts to incorrect overzealous autofill.
Update Mar 2020
It is not clear if and when this solution still works. It appears to still work sometimes but not all the time.
In the comments below you will find a few hints. One just added by #anilyeni may be worth some more investigation:
As I noticed, autocomplete="off" works on Chrome 80, if there are fewer than three elements in <form>. I don't know what is the logic or where the related documentation about it.
Also this one from #dubrox may be relevant, although I have not tested it:
thanks a lot for the trick, but please update the answer, as display:none; doesn't work anymore, but position: fixed;top:-100px;left:-100px; width:5px; does :)
Update APRIL 2020
Special value for chrome for this attribute is doing the job: (tested on input - but not by me)
autocomplete="chrome-off"
After months and months of struggle, I have found that the solution is a lot simpler than you could imagine:
Instead of autocomplete="off" use autocomplete="false" ;)
As simple as that, and it works like a charm in Google Chrome as well!
August 2019 update (credit to #JonEdiger in comments)
Note: lots of info online says the browsers now treat autocomplete='false' to be the same as autocomplete='off'. At least as of right this minute, it is preventing autocomplete for those three browsers.
Set it at form level and then for the inputs you want it off, set to some non-valid value like 'none':
<form autocomplete="off">
<input type="text" id="lastName" autocomplete="none"/>
<input type="text" id="firstName" autocomplete="none"/>
</form>
Sometimes even autocomplete=off won't prevent filling in credentials into wrong fields.
A workaround is to disable browser autofill using readonly-mode and set writable on focus:
<input type="password" readonly onfocus="this.removeAttribute('readonly');"/>
The focus event occurs at mouse clicks and tabbing through fields.
Update:
Mobile Safari sets cursor in the field, but does not show virtual keyboard. This new workaround works like before, but handles virtual keyboard:
<input id="email" readonly type="email" onfocus="if (this.hasAttribute('readonly')) {
this.removeAttribute('readonly');
// fix for mobile safari to show virtual keyboard
this.blur(); this.focus(); }" />
Live Demo https://jsfiddle.net/danielsuess/n0scguv6/
// UpdateEnd
Explanation: Browser auto fills credentials to wrong text field?
filling the inputs incorrectly, for example filling the phone input with an email address
Sometimes I notice this strange behavior on Chrome and Safari, when there are password fields in the same form. I guess, the browser looks for a password field to insert your saved credentials. Then it autofills username into the nearest textlike-input field , that appears prior the password field in DOM (just guessing due to observation). As the browser is the last instance and you can not control it,
This readonly-fix above worked for me.
If you are implementing a search box feature, try setting the type attribute to search as follows:
<input type="search" autocomplete="off" />
This is working for me on Chrome v48 and appears to be legitimate markup:
https://www.w3.org/wiki/HTML/Elements/input/search
I don't know why, but this helped and worked for me.
<input type="password" name="pwd" autocomplete="new-password">
I have no idea why, but autocomplete="new-password" disables autofill. It worked in latest 49.0.2623.112 chrome version.
Try this. I know the question is somewhat old, but this is a different approach for the problem.
I also noticed the issue comes just above the password field.
I tried both the methods like
<form autocomplete="off"> and <input autocomplete="off"> but none of them worked for me.
So I fixed it using the snippet below - just added another text field just above the password type field and made it display:none.
Something like this:
<input type="text" name="prevent_autofill" id="prevent_autofill" value="" style="display:none;" />
<input type="password" name="password_fake" id="password_fake" value="" style="display:none;" />
<input type="password" name="password" id="password" value="" />
Hope it will help someone.
For me, simple
<form autocomplete="off" role="presentation">
Did it.
Tested on multiple versions, last try was on 56.0.2924.87
You have to add this attribute :
autocomplete="new-password"
Source Link : Full Article
It is so simple and tricky :)
google chrome basically search for every first visible password element inside the <form>, <body> and <iframe> tags to enable auto refill for them, so to disable this you need to add a dummy password element as the following:
if your password element inside a <form> tag you need to put the dummy element as the first element in your form immediately after <form> open tag
if your password element not inside a <form> tag put the dummy element as the first element in your html page immediately after <body> open tag
You need to hide the dummy element without using css display:none so basically use the following as a dummy password element.
<input type="password" style="width: 0;height: 0; visibility: hidden;position:absolute;left:0;top:0;"/>
Here are my proposed solutions, since Google are insisting on overriding every work-around that people seem to make.
Option 1 - select all text on click
Set the values of the inputs to an example for your user (e.g. your#email.com), or the label of the field (e.g. Email) and add a class called focus-select to your inputs:
<input type="text" name="email" class="focus-select" value="your#email.com">
<input type="password" name="password" class="focus-select" value="password">
And here's the jQuery:
$(document).on('click', '.focus-select', function(){
$(this).select();
});
I really can't see Chrome ever messing with values. That'd be crazy. So hopefully this is a safe solution.
Option 2 - set the email value to a space, then delete it
Assuming you have two inputs, such as email and password, set the value of the email field to " " (a space) and add the attribute/value autocomplete="off", then clear this with JavaScript. You can leave the password value empty.
If the user doesn't have JavaScript for some reason, ensure you trim their input server-side (you probably should be anyway), in case they don't delete the space.
Here's the jQuery:
$(document).ready(function() {
setTimeout(function(){
$('[autocomplete=off]').val('');
}, 15);
});
I set a timeout to 15 because 5 seemed to work occasionally in my tests, so trebling this number seems like a safe bet.
Failing to set the initial value to a space results in Chrome leaving the input as yellow, as if it has auto-filled it.
Option 3 - hidden inputs
Put this at the beginning of the form:
<!-- Avoid Chrome autofill -->
<input name="email" class="hide">
CSS:
.hide{ display:none; }
Ensure you keep the HTML note so that your other developers don't delete it! Also ensure the name of the hidden input is relevant.
Use css text-security: disc without using type=password.
html
<input type='text' name='user' autocomplete='off' />
<input type='text' name='pass' autocomplete='off' class='secure' />
or
<form autocomplete='off'>
<input type='text' name='user' />
<input type='text' name='pass' class='secure' />
</form>
css
input.secure {
text-security: disc;
-webkit-text-security: disc;
}
Previously entered values cached by chrome is displayed as dropdown select list.This can be disabled by autocomplete=off , explicitly saved address in advanced settings of chrome gives autofill popup when an address field gets focus.This can be disabled by autocomplete="false".But it will allow chrome to display cached values in dropdown.
On an input html field following will switch off both.
Role="presentation" & autocomplete="off"
While selecting input fields for address autofill Chrome ignores those input fields which don't have preceding label html element.
To ensure chrome parser ignores an input field for autofill address popup a hidden button or image control can be added between label and textbox. This will break chrome parsing sequence of label -input pair creation for autofill.
Checkboxes are ignored while parsing for address fields
Chrome also considers "for" attribute on label element. It can be used to break parsing sequence of chrome.
In some cases, the browser will keep suggesting autocompletion values even if the autocomplete attribute is set to off. This unexpected behavior can be quite puzzling for developers. The trick to really forcing the no-autocompletion is to assign a random string to the attribute, for example:
autocomplete="nope"
I've found that adding this to a form prevents Chrome from using Autofill.
<div style="display: none;">
<input type="text" id="PreventChromeAutocomplete" name="PreventChromeAutocomplete" autocomplete="address-level4" />
</div>
Found here. https://code.google.com/p/chromium/issues/detail?id=468153#hc41
Really disappointing that Chrome has decided that it knows better than the developer about when to Autocomplete. Has a real Microsoft feel to it.
<input readonly onfocus="this.removeAttribute('readonly');" type="text">
adding readonly attribute to the tag along with the onfocus event removing it fixes the issue
In 2016 Google Chrome started ignoring autocomplete=off though it is in W3C. The answer they posted:
The tricky part here is that somewhere along the journey of the web autocomplete=off become a default for many form fields, without any real thought being given as to whether or not that was good for users. This doesn't mean there aren't very valid cases where you don't want the browser autofilling data (e.g. on CRM systems), but by and large, we see those as the minority cases. And as a result, we started ignoring autocomplete=off for Chrome Autofill data.
Which essentially says: we know better what a user wants.
They opened another bug to post valid use cases when autocomplete=off is required
I haven't seen issues connected with autocomplete throught all my B2B application but only with input of a password type.
Autofill steps in if there's any password field on the screen even a hidden one.
To break this logic you can put each password field into it's own form if it doesn't break your own page logic.
<input type=name >
<form>
<input type=password >
</form>
For username password combos this is an easy issue to resolve. Chrome heuristics looks for the pattern:
<input type="text">
followed by:
<input type="password">
Simply break this process by invalidating this:
<input type="text">
<input type="text" onfocus="this.type='password'">
Mike Nelsons provided solution did not work for me in Chrome 50.0.2661.102 m.
Simply adding an input element of the same type with display:none set no longer disables the native browser auto-complete. It is now necessary to duplicate the name attribute of the input field you wish to disable auto-complete on.
Also, to avoid having the input field duplicated when they are within a form element you should place a disabled on the element which is not displayed. This will prevent that element from being submitted as part of the form action.
<input name="dpart" disabled="disabled" type="password" style="display:none;">
<input name="dpart" type="password">
<input type="submit">
There's two pieces to this. Chrome and other browsers will remember previously entered values for field names, and provide an autocomplete list to the user based on that (notably, password type inputs are never remembered in this way, for fairly obvious reasons). You can add autocomplete="off" to prevent this on things like your email field.
However, you then have password fillers. Most browsers have their own built-in implementations and there's also many third-party utilities that provide this functionality. This, you can't stop. This is the user making their own choice to save this information to be automatically filled in later, and is completely outside the scope and sphere of influence of your application.
If you're having issues with keeping placeholders but disabling the chrome autofill I found this workaround.
Problem
HTML
<div class="form">
<input type="text" placeholder="name"><br>
<input type="text" placeholder="email"><br>
<input type="text" placeholder="street"><br>
</div>
http://jsfiddle.net/xmbvwfs6/1/
The above example still produces the autofill problem, but if you use the required="required" and some CSS you can replicate the placeholders and Chrome won't pick up the tags.
Solution
HTML
<div class="form">
<input type="text" required="required">
<label>Name</label>
<br>
<input type="text" required="required">
<label>Email</label>
<br>
<input type="text" required="required">
<label>Street</label>
<br>
</div>
CSS
input {
margin-bottom: 10px;
width: 200px;
height: 20px;
padding: 0 10px;
font-size: 14px;
}
input + label {
position: relative;
left: -216px;
color: #999;
font-size: 14px;
}
input:invalid + label {
display: inline-block;
}
input:valid + label {
display: none;
}
http://jsfiddle.net/mwshpx1o/1/
I really did not like making hidden fields, I think that making it like that will get really confusing really fast.
On the input fields that you want to stop from auto complete this will work. Make the fields read only and on focus remove that attribute like this
<input readonly onfocus="this.removeAttribute('readonly');" type="text">
what this does is you first have to remove the read only attribute by selecting the field and at that time most-likely you will populated with your own user input and stooping the autofill to take over
As per Chromium bug report #352347 Chrome no longer respects autocomplete="off|false|anythingelse", neither on forms nor on inputs.
The only solution that worked for me was to add a dummy password field:
<input type="password" class="hidden" />
<input type="password" />
By setting autocomplete to off should work here I have an example which is used by google in search page. I found this from inspect element.
edit:
In case off isn't working then try false or nofill. In my case it is working with chrome version 48.0
Well since we all have this problem I invested some time to write a working jQuery extension for this issue. Google has to follow html markup, not we follow Google
(function ($) {
"use strict";
$.fn.autoCompleteFix = function(opt) {
var ro = 'readonly', settings = $.extend({
attribute : 'autocomplete',
trigger : {
disable : ["off"],
enable : ["on"]
},
focus : function() {
$(this).removeAttr(ro);
},
force : false
}, opt);
$(this).each(function(i, el) {
el = $(el);
if(el.is('form')) {
var force = (-1 !== $.inArray(el.attr(settings.attribute), settings.trigger.disable))
el.find('input').autoCompleteFix({force:force});
} else {
var disabled = -1 !== $.inArray(el.attr(settings.attribute), settings.trigger.disable);
var enabled = -1 !== $.inArray(el.attr(settings.attribute), settings.trigger.enable);
if (settings.force && !enabled || disabled)
el.attr(ro, ro).focus(settings.focus).val("");
}
});
};
})(jQuery);
Just add this to a file like /js/jquery.extends.js and include it past jQuery.
Apply it to each form elements on load of the document like this:
$(function() {
$('form').autoCompleteFix();
});
jsfiddle with tests
Try the following jQuery code which has worked for me.
if ($.browser.webkit) {
$('input[name="password"]').attr('autocomplete', 'off');
$('input[name="email"]').attr('autocomplete', 'off');
}
Here's a dirty hack -
You have your element here (adding the disabled attribute):
<input type="text" name="test" id="test" disabled="disabled" />
And then at the bottom of your webpage put some JavaScript:
<script>
setTimeout(function(){
document.getElementById('test').removeAttribute("disabled");
},100);
</script>
Different solution, webkit based. As mentioned already, anytime Chrome finds a password field it autocompletes the email. AFAIK, this is regardless of autocomplete = [whatever].
To circumvent this change the input type to text and apply the webkit security font in whatever form you want.
.secure-font{
-webkit-text-security:disc;}
<input type ="text" class="secure-font">
From what I can see this is at least as secure as input type=password, it's copy and paste secure. However it is vulnerable by removing the style which will remove asterisks, of course input type = password can easily be changed to input type = text in the console to reveal any autofilled passwords so it's much the same really.
I've finally found success using a textarea. For a password field there's an event handler that replaces each character typed with a "•".
I've faced same problem. And here is the solution for disable auto-fill user name & password on Chrome (just tested with Chrome only)
<!-- Just add this hidden field before password as a charmed solution to prevent auto-fill of browser on remembered password -->
<input type="tel" hidden />
<input type="password" ng-minlength="8" ng-maxlength="30" ng-model="user.password" name="password" class="form-control" required placeholder="Input password">

Is there any solution for "autocomplete=off" property is not working? [duplicate]

This question's answers are a community effort. Edit existing answers to improve this post. It is not currently accepting new answers or interactions.
I have been running into issues with the chrome autofill behavior on several forms.
The fields in the form all have very common and accurate names, such as "email", "name", or "password", and they also have autocomplete="off" set.
The autocomplete flag has successfully disabled the autocomplete behavior, where a dropdown of values appear as you start typing, but has not changed the values that Chrome auto-populates the fields as.
This behavior would be ok except that chrome is filling the inputs incorrectly, for example filling the phone input with an email address. Customers have complained about this, so it's verified to be happening in multiple cases, and not as some some sort of result to something that I've done locally on my machine.
The only current solution I can think of is to dynamically generate custom input names and then extract the values on the backend, but this seems like a pretty hacky way around this issue. Are there any tags or quirks that change the autofill behavior that could be used to fix this?
Apr 2022: autocomplete="off" still does not work in Chrome, and I don't believe it ever has after looking through the Chromium bugs related to the issue (maybe only for password fields). I see issues reported in 2014 that were closed as "WontFix", and issues still open and under discussion [1][2]. From what I gather the Chromium team doesn't believe there is a valid use case for autocomplete="off".
Overall, I still believe that neither of the extreme strategies ("always honor autocomplete=off" and "never honor autocomplete=off") are good.
https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c66
They are under the impression that websites won't use this correctly and have decided not to apply it, suggesting the following advice:
In cases where you want to disable autofill, our suggestion is to
utilize the autocomplete attribute to give semantic meaning to your
fields. If we encounter an autocomplete attribute that we don't
recognize, we won't try and fill it.
As an example, if you have an address input field in your CRM tool
that you don't want Chrome to Autofill, you can give it semantic
meaning that makes sense relative to what you're asking for: e.g.
autocomplete="new-user-street-address". If Chrome encounters that, it
won't try and autofill the field.
https://bugs.chromium.org/p/chromium/issues/detail?id=587466#c10
Although this "suggestion" currently works for me it may not always hold true and it looks like the team is running experiments, meaning the autocomplete functionality could change in new releases.
It's silly that we have to resort to this, but the only sure way is to try and confuse the browser as much as possible:
Name your inputs without leaking any information to the browser, i.e. id="field1" instead of id="country".
Set autocomplete="do-not-autofill", basically use any value that won't let the browser recognize it as an autofillable field.
Jan 2021: autocomplete="off" does work as expected now (tested on Chrome 88 macOS).
For this to work be sure to have your input tag within a Form tag
Sept 2020: autocomplete="chrome-off" disables Chrome autofill.
Original answer, 2015:
For new Chrome versions you can just put autocomplete="new-password" in your password field and that's it. I've checked it, works fine.
Got that tip from Chrome developer in this discussion:
https://bugs.chromium.org/p/chromium/issues/detail?id=370363#c7
P.S. Note that Chrome will attempt to infer autofill behavior from name, id and any text content it can get surrounding the field including labels and arbitrary text nodes. If there is a autocomplete token like street-address in context, Chrome will autofill that as such. The heuristic can be quite confusing as it sometimes only trigger if there are additional fields in the form, or not if there are too few fields in the form. Also note that autocomplete="no" will appear to work but autocomplete="off" will not for historical reasons. autocomplete="no" is you telling the browser that this field should be auto completed as a field called "no". If you generate unique random autocomplete names you disable auto complete.
If your users have visited bad forms their autofill information may be corrupt. Having them manually go in and fix their autofill information in Chrome may be a necessary action from them to take.
I've just found that if you have a remembered username and password for a site, the current version of Chrome will autofill your username/email address into the field before any type=password field. It does not care what the field is called - just assumes the field before password is going to be your username.
Old Solution
Just use <form autocomplete="off"> and it prevents the password prefilling as well as any kind of heuristic filling of fields based on assumptions a browser may make (which are often wrong). As opposed to using <input autocomplete="off"> which seems to be pretty much ignored by the password autofill (in Chrome that is, Firefox does obey it).
Updated Solution
Chrome now ignores <form autocomplete="off">. Therefore my original workaround (which I had deleted) is now all the rage.
Simply create a couple of fields and make them hidden with "display:none". Example:
<!-- fake fields are a workaround for chrome autofill getting the wrong fields -->
<input style="display: none" type="text" name="fakeusernameremembered" />
<input style="display: none" type="password" name="fakepasswordremembered" />
Then put your real fields underneath.
Remember to add the comment or other people on your team will wonder what you are doing!
Update March 2016
Just tested with latest Chrome - all good. This is a fairly old answer now but I want to just mention that our team has been using it for years now on dozens of projects. It still works great despite a few comments below. There are no problems with accessibility because the fields are display:none meaning they don't get focus. As I mentioned you need to put them before your real fields.
If you are using javascript to modify your form, there is an extra trick you will need. Show the fake fields while you are manipulating the form and then hide them again a millisecond later.
Example code using jQuery (assuming you give your fake fields a class):
$(".fake-autofill-fields").show();
// some DOM manipulation/ajax here
window.setTimeout(function () {
$(".fake-autofill-fields").hide();
}, 1);
Update July 2018
My solution no longer works so well since Chrome's anti-usability experts have been hard at work. But they've thrown us a bone in the form of:
<input type="password" name="whatever" autocomplete="new-password" />
This works and mostly solves the problem.
However, it does not work when you don't have a password field but only an email address. That can also be difficult to get it to stop going yellow and prefilling. The fake fields solution can be used to fix this.
In fact you sometimes need to drop in two lots of fake fields, and try them in different places. For example, I already had fake fields at the beginning of my form, but Chrome recently started prefilling my 'Email' field again - so then I doubled down and put in more fake fields just before the 'Email' field, and that fixed it. Removing either the first or second lot of the fields reverts to incorrect overzealous autofill.
Update Mar 2020
It is not clear if and when this solution still works. It appears to still work sometimes but not all the time.
In the comments below you will find a few hints. One just added by #anilyeni may be worth some more investigation:
As I noticed, autocomplete="off" works on Chrome 80, if there are fewer than three elements in <form>. I don't know what is the logic or where the related documentation about it.
Also this one from #dubrox may be relevant, although I have not tested it:
thanks a lot for the trick, but please update the answer, as display:none; doesn't work anymore, but position: fixed;top:-100px;left:-100px; width:5px; does :)
Update APRIL 2020
Special value for chrome for this attribute is doing the job: (tested on input - but not by me)
autocomplete="chrome-off"
After months and months of struggle, I have found that the solution is a lot simpler than you could imagine:
Instead of autocomplete="off" use autocomplete="false" ;)
As simple as that, and it works like a charm in Google Chrome as well!
August 2019 update (credit to #JonEdiger in comments)
Note: lots of info online says the browsers now treat autocomplete='false' to be the same as autocomplete='off'. At least as of right this minute, it is preventing autocomplete for those three browsers.
Set it at form level and then for the inputs you want it off, set to some non-valid value like 'none':
<form autocomplete="off">
<input type="text" id="lastName" autocomplete="none"/>
<input type="text" id="firstName" autocomplete="none"/>
</form>
Sometimes even autocomplete=off won't prevent filling in credentials into wrong fields.
A workaround is to disable browser autofill using readonly-mode and set writable on focus:
<input type="password" readonly onfocus="this.removeAttribute('readonly');"/>
The focus event occurs at mouse clicks and tabbing through fields.
Update:
Mobile Safari sets cursor in the field, but does not show virtual keyboard. This new workaround works like before, but handles virtual keyboard:
<input id="email" readonly type="email" onfocus="if (this.hasAttribute('readonly')) {
this.removeAttribute('readonly');
// fix for mobile safari to show virtual keyboard
this.blur(); this.focus(); }" />
Live Demo https://jsfiddle.net/danielsuess/n0scguv6/
// UpdateEnd
Explanation: Browser auto fills credentials to wrong text field?
filling the inputs incorrectly, for example filling the phone input with an email address
Sometimes I notice this strange behavior on Chrome and Safari, when there are password fields in the same form. I guess, the browser looks for a password field to insert your saved credentials. Then it autofills username into the nearest textlike-input field , that appears prior the password field in DOM (just guessing due to observation). As the browser is the last instance and you can not control it,
This readonly-fix above worked for me.
If you are implementing a search box feature, try setting the type attribute to search as follows:
<input type="search" autocomplete="off" />
This is working for me on Chrome v48 and appears to be legitimate markup:
https://www.w3.org/wiki/HTML/Elements/input/search
I don't know why, but this helped and worked for me.
<input type="password" name="pwd" autocomplete="new-password">
I have no idea why, but autocomplete="new-password" disables autofill. It worked in latest 49.0.2623.112 chrome version.
Try this. I know the question is somewhat old, but this is a different approach for the problem.
I also noticed the issue comes just above the password field.
I tried both the methods like
<form autocomplete="off"> and <input autocomplete="off"> but none of them worked for me.
So I fixed it using the snippet below - just added another text field just above the password type field and made it display:none.
Something like this:
<input type="text" name="prevent_autofill" id="prevent_autofill" value="" style="display:none;" />
<input type="password" name="password_fake" id="password_fake" value="" style="display:none;" />
<input type="password" name="password" id="password" value="" />
Hope it will help someone.
For me, simple
<form autocomplete="off" role="presentation">
Did it.
Tested on multiple versions, last try was on 56.0.2924.87
You have to add this attribute :
autocomplete="new-password"
Source Link : Full Article
It is so simple and tricky :)
google chrome basically search for every first visible password element inside the <form>, <body> and <iframe> tags to enable auto refill for them, so to disable this you need to add a dummy password element as the following:
if your password element inside a <form> tag you need to put the dummy element as the first element in your form immediately after <form> open tag
if your password element not inside a <form> tag put the dummy element as the first element in your html page immediately after <body> open tag
You need to hide the dummy element without using css display:none so basically use the following as a dummy password element.
<input type="password" style="width: 0;height: 0; visibility: hidden;position:absolute;left:0;top:0;"/>
Here are my proposed solutions, since Google are insisting on overriding every work-around that people seem to make.
Option 1 - select all text on click
Set the values of the inputs to an example for your user (e.g. your#email.com), or the label of the field (e.g. Email) and add a class called focus-select to your inputs:
<input type="text" name="email" class="focus-select" value="your#email.com">
<input type="password" name="password" class="focus-select" value="password">
And here's the jQuery:
$(document).on('click', '.focus-select', function(){
$(this).select();
});
I really can't see Chrome ever messing with values. That'd be crazy. So hopefully this is a safe solution.
Option 2 - set the email value to a space, then delete it
Assuming you have two inputs, such as email and password, set the value of the email field to " " (a space) and add the attribute/value autocomplete="off", then clear this with JavaScript. You can leave the password value empty.
If the user doesn't have JavaScript for some reason, ensure you trim their input server-side (you probably should be anyway), in case they don't delete the space.
Here's the jQuery:
$(document).ready(function() {
setTimeout(function(){
$('[autocomplete=off]').val('');
}, 15);
});
I set a timeout to 15 because 5 seemed to work occasionally in my tests, so trebling this number seems like a safe bet.
Failing to set the initial value to a space results in Chrome leaving the input as yellow, as if it has auto-filled it.
Option 3 - hidden inputs
Put this at the beginning of the form:
<!-- Avoid Chrome autofill -->
<input name="email" class="hide">
CSS:
.hide{ display:none; }
Ensure you keep the HTML note so that your other developers don't delete it! Also ensure the name of the hidden input is relevant.
Use css text-security: disc without using type=password.
html
<input type='text' name='user' autocomplete='off' />
<input type='text' name='pass' autocomplete='off' class='secure' />
or
<form autocomplete='off'>
<input type='text' name='user' />
<input type='text' name='pass' class='secure' />
</form>
css
input.secure {
text-security: disc;
-webkit-text-security: disc;
}
Previously entered values cached by chrome is displayed as dropdown select list.This can be disabled by autocomplete=off , explicitly saved address in advanced settings of chrome gives autofill popup when an address field gets focus.This can be disabled by autocomplete="false".But it will allow chrome to display cached values in dropdown.
On an input html field following will switch off both.
Role="presentation" & autocomplete="off"
While selecting input fields for address autofill Chrome ignores those input fields which don't have preceding label html element.
To ensure chrome parser ignores an input field for autofill address popup a hidden button or image control can be added between label and textbox. This will break chrome parsing sequence of label -input pair creation for autofill.
Checkboxes are ignored while parsing for address fields
Chrome also considers "for" attribute on label element. It can be used to break parsing sequence of chrome.
In some cases, the browser will keep suggesting autocompletion values even if the autocomplete attribute is set to off. This unexpected behavior can be quite puzzling for developers. The trick to really forcing the no-autocompletion is to assign a random string to the attribute, for example:
autocomplete="nope"
I've found that adding this to a form prevents Chrome from using Autofill.
<div style="display: none;">
<input type="text" id="PreventChromeAutocomplete" name="PreventChromeAutocomplete" autocomplete="address-level4" />
</div>
Found here. https://code.google.com/p/chromium/issues/detail?id=468153#hc41
Really disappointing that Chrome has decided that it knows better than the developer about when to Autocomplete. Has a real Microsoft feel to it.
<input readonly onfocus="this.removeAttribute('readonly');" type="text">
adding readonly attribute to the tag along with the onfocus event removing it fixes the issue
In 2016 Google Chrome started ignoring autocomplete=off though it is in W3C. The answer they posted:
The tricky part here is that somewhere along the journey of the web autocomplete=off become a default for many form fields, without any real thought being given as to whether or not that was good for users. This doesn't mean there aren't very valid cases where you don't want the browser autofilling data (e.g. on CRM systems), but by and large, we see those as the minority cases. And as a result, we started ignoring autocomplete=off for Chrome Autofill data.
Which essentially says: we know better what a user wants.
They opened another bug to post valid use cases when autocomplete=off is required
I haven't seen issues connected with autocomplete throught all my B2B application but only with input of a password type.
Autofill steps in if there's any password field on the screen even a hidden one.
To break this logic you can put each password field into it's own form if it doesn't break your own page logic.
<input type=name >
<form>
<input type=password >
</form>
For username password combos this is an easy issue to resolve. Chrome heuristics looks for the pattern:
<input type="text">
followed by:
<input type="password">
Simply break this process by invalidating this:
<input type="text">
<input type="text" onfocus="this.type='password'">
Mike Nelsons provided solution did not work for me in Chrome 50.0.2661.102 m.
Simply adding an input element of the same type with display:none set no longer disables the native browser auto-complete. It is now necessary to duplicate the name attribute of the input field you wish to disable auto-complete on.
Also, to avoid having the input field duplicated when they are within a form element you should place a disabled on the element which is not displayed. This will prevent that element from being submitted as part of the form action.
<input name="dpart" disabled="disabled" type="password" style="display:none;">
<input name="dpart" type="password">
<input type="submit">
There's two pieces to this. Chrome and other browsers will remember previously entered values for field names, and provide an autocomplete list to the user based on that (notably, password type inputs are never remembered in this way, for fairly obvious reasons). You can add autocomplete="off" to prevent this on things like your email field.
However, you then have password fillers. Most browsers have their own built-in implementations and there's also many third-party utilities that provide this functionality. This, you can't stop. This is the user making their own choice to save this information to be automatically filled in later, and is completely outside the scope and sphere of influence of your application.
If you're having issues with keeping placeholders but disabling the chrome autofill I found this workaround.
Problem
HTML
<div class="form">
<input type="text" placeholder="name"><br>
<input type="text" placeholder="email"><br>
<input type="text" placeholder="street"><br>
</div>
http://jsfiddle.net/xmbvwfs6/1/
The above example still produces the autofill problem, but if you use the required="required" and some CSS you can replicate the placeholders and Chrome won't pick up the tags.
Solution
HTML
<div class="form">
<input type="text" required="required">
<label>Name</label>
<br>
<input type="text" required="required">
<label>Email</label>
<br>
<input type="text" required="required">
<label>Street</label>
<br>
</div>
CSS
input {
margin-bottom: 10px;
width: 200px;
height: 20px;
padding: 0 10px;
font-size: 14px;
}
input + label {
position: relative;
left: -216px;
color: #999;
font-size: 14px;
}
input:invalid + label {
display: inline-block;
}
input:valid + label {
display: none;
}
http://jsfiddle.net/mwshpx1o/1/
I really did not like making hidden fields, I think that making it like that will get really confusing really fast.
On the input fields that you want to stop from auto complete this will work. Make the fields read only and on focus remove that attribute like this
<input readonly onfocus="this.removeAttribute('readonly');" type="text">
what this does is you first have to remove the read only attribute by selecting the field and at that time most-likely you will populated with your own user input and stooping the autofill to take over
As per Chromium bug report #352347 Chrome no longer respects autocomplete="off|false|anythingelse", neither on forms nor on inputs.
The only solution that worked for me was to add a dummy password field:
<input type="password" class="hidden" />
<input type="password" />
By setting autocomplete to off should work here I have an example which is used by google in search page. I found this from inspect element.
edit:
In case off isn't working then try false or nofill. In my case it is working with chrome version 48.0
Well since we all have this problem I invested some time to write a working jQuery extension for this issue. Google has to follow html markup, not we follow Google
(function ($) {
"use strict";
$.fn.autoCompleteFix = function(opt) {
var ro = 'readonly', settings = $.extend({
attribute : 'autocomplete',
trigger : {
disable : ["off"],
enable : ["on"]
},
focus : function() {
$(this).removeAttr(ro);
},
force : false
}, opt);
$(this).each(function(i, el) {
el = $(el);
if(el.is('form')) {
var force = (-1 !== $.inArray(el.attr(settings.attribute), settings.trigger.disable))
el.find('input').autoCompleteFix({force:force});
} else {
var disabled = -1 !== $.inArray(el.attr(settings.attribute), settings.trigger.disable);
var enabled = -1 !== $.inArray(el.attr(settings.attribute), settings.trigger.enable);
if (settings.force && !enabled || disabled)
el.attr(ro, ro).focus(settings.focus).val("");
}
});
};
})(jQuery);
Just add this to a file like /js/jquery.extends.js and include it past jQuery.
Apply it to each form elements on load of the document like this:
$(function() {
$('form').autoCompleteFix();
});
jsfiddle with tests
Try the following jQuery code which has worked for me.
if ($.browser.webkit) {
$('input[name="password"]').attr('autocomplete', 'off');
$('input[name="email"]').attr('autocomplete', 'off');
}
Here's a dirty hack -
You have your element here (adding the disabled attribute):
<input type="text" name="test" id="test" disabled="disabled" />
And then at the bottom of your webpage put some JavaScript:
<script>
setTimeout(function(){
document.getElementById('test').removeAttribute("disabled");
},100);
</script>
Different solution, webkit based. As mentioned already, anytime Chrome finds a password field it autocompletes the email. AFAIK, this is regardless of autocomplete = [whatever].
To circumvent this change the input type to text and apply the webkit security font in whatever form you want.
.secure-font{
-webkit-text-security:disc;}
<input type ="text" class="secure-font">
From what I can see this is at least as secure as input type=password, it's copy and paste secure. However it is vulnerable by removing the style which will remove asterisks, of course input type = password can easily be changed to input type = text in the console to reveal any autofilled passwords so it's much the same really.
I've finally found success using a textarea. For a password field there's an event handler that replaces each character typed with a "•".
I've faced same problem. And here is the solution for disable auto-fill user name & password on Chrome (just tested with Chrome only)
<!-- Just add this hidden field before password as a charmed solution to prevent auto-fill of browser on remembered password -->
<input type="tel" hidden />
<input type="password" ng-minlength="8" ng-maxlength="30" ng-model="user.password" name="password" class="form-control" required placeholder="Input password">

How to use Regular Expressions with a Form using Angular (no jQuery)

I have a simple input field. I want to make sure certain rules are met before submission
The password must:
0. have at least 8 characters
1. have no more than 8 characters
2. have both upper and lower case characters
3. have at least 1 letters
4. have at least 1 digits
5. have one of # # $
6. contain only characters available on a standard English (US) keyboard. List of valid characters
7. not be an old password
My Html Form
<form name="login" action="index_submit" method="get" accept-charset="utf-8">
<ul>
<li><label for="username">Email</label>
<input type="email" name="username" placeholder="username#example.com" required></li>
<li><label for="password">Current Password</label>
<input type="password" name="current_password" placeholder="current password" required></li>
<li><label for="password">New Password</label>
<input type="password" name="new_password" placeholder="new password" required></li>
<li>
<input type="submit" value="Login"></li>
</ul>
</form>
I only want to apply the rules to the "new_password"
Add a checkmark (green) if the rules are successful or red X if they don't meet the criteria.
I am new to Angular but not new to RegEx. I have the Expression
"^(?=.{8}$)(?=.*[A-Z])(?=.*[0-9])(?=.*[,##$])"
It would be nice to know which of the rules it has been violated
You can use ngPattern on the input. More information here.
You can use ng-pattern for Regex. This will not allow you to know which of the rules encoded in your pattern were violated. For that, you may want to use a combination of directives like, ng-minlength, ng-maxlength.
Take a look at: https://docs.angularjs.org/guide/forms
You can also use custom $validators in order to apply specific validation logic to your fields (but like the other posters mentioned, ng-pattern is great for that purpose).
It's working in conjunction with models, when you model changes (= the field value changes), it's checking it against the custom registered $validators (through a directive for instance) and updating the model with the results of the validation.
Here is a working plunkr with your regexp: http://embed.plnkr.co/CdITVLnZOZgAzrqAV4iA/preview
(you can use the code view to check out how it's done)
You can also read the AngularJs documentation about forms, you can do a lot of interesting stuff using directives and models within your forms.
https://docs.angularjs.org/guide/forms

Input Number Type Dollar Sign

I have a form with a line that asks for a dollar amount, however if the user puts a dollar sign in front of the number the form won't let it send because it is set to type="number".
Is there a way to let a user type in a dollar sign ($) in the type="number" and have the form send with no issue?
Code:
<label>Monthly Budget</label>
<input name="budget" type="number" placeholder="$400.00" required data-errormessage-value-missing="Uh oh, somethings wrong!" data-errormessage-type-mismatch="Uh oh, somethings wrong!">
Just denote the symbol before the input field so they don't add it again. Currency symbols aren't handled in code, they're added to the viewport for the users display on-the-fly.
<label>Monthly Budget</label>
<span class="input">$<input name="budget" type="number" placeholder="400.00" required data-errormessage-value-missing="Uh oh, somethings wrong!" data-errormessage-type-mismatch="Uh oh, somethings wrong!"></span>
Example
input type=number - Reference
The only way to let a user type in a dollar sign in a type="number" field and have the form send with no issue is to intercept (with JavaScript) user input with keyboard event handlers such as onkeyup, remove the dollar sign, and clear the status with setCustomValidity(''). This would require some care, since keyboard event handling (and recognizing which character was entered) varies across browsers. More importantly, it would result in poor usability: the user could type “$42” but would see the “$” vanish, and could get very confused.
Putting the dollar sign in front of the field is one way (not completely reliable) of avoiding the problem of a user-entered dollar sign (rather than solving it). Note that there are other issues with the code, too, such as the use of a specific amount of money as a placeholder (use value if you wish to set an initial value) and not allowing any cents, contrary to what 400.00 suggests. A better idea:
<label for="budget">Monthly Budget</label>
<input id="budget" name="budget" type="number"
placeholder="xxx.xx"
required
step="0.01"
title="Amount of money in numbers">
(If you wish to disallow cents, which would be sensible for a budget, omit the step attribute, defaulting it to 1, and omit the placeholder attribute, since there’s probably no suitable value for it.)
Alternatively, use input type="text" and a suitable pattern attribute, e.g.
<input id="budget" name="budget" type="text"
placeholder="xxx.xx"
required
title="Amount of money in numbers"
pattern="\$?(\d)+(\.\d\d)?">
(to allow cents but not require them). Note that this would make (on supporting browsers) input like 400.000 or 400.5 invalid, which is probably good. This approach would imply that in form data handling, you would need to deal with an optional leading “$”, which is normally simple of course.

Use custom regular expressions to validate form

I would like to validate the form using my custom data attributes but not sure how this is done. I also want to display the error messages in the data attributes if required.
I am looking for the JavaScript which matches the regex values from the data attributes and matches it against the corresponding input values.
I have the following form..
<form id="loginForm" name="loginForm">
<ul>
<li>
<label for="Username">Username:</label>
<input type="email" data-validation-error="Please enter a username" data-validation-use="^([a-zA-Z0-9_\-\.]+)#((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$" id="username" name="username" maxlength="254" class="required" />
</li>
<li>
<label for="Password">Password:</label>
<input type="password" data-validation-error="Please enter a password" data-validation-use="^[a-zA-Z]\w{5,12}$" id="password" name="password" value="" maxlength="12" class="required" />
</li>
</ul>
<input type="submit" value="Login" class="button" name="loginBtn" id="loginBtn" />
</form>
If you're developing for modern browsers only, you can use a few nice features for this:
List itemUse input type email for the username field. The browser will take care of the validation.
Use attribute required. The browser won't let the user submit without a value in the field.
Use attribute pattern. The browser won't let the user submit without the value matching the given pattern. Altough, with email type, you could skip the horrible regex matching emails of yours :)
Check out the pattern attribute:
http://www.the-art-of-web.com/html/html5-form-validation/#section_6
Example:
<input type="email" required />
Here you can check out the support for modern form features in the most used browsers:
http://caniuse.com/#feat=forms
There is an ongoing discussion if it should be possible to specify and style the error messages (handled by the browser). As for now, I don't think it's possible to style the validation messages. Maybe it's more user friendly if these messages is equal across all pages?
If you need to support older browsers, you'll have to put javascript event handlers on each field, extract the regex from the data attributes and match it against the value. Keep in mind that client side validation is no substitute for server side validation - it's just for user convenience. Therefore, HTML5 validation could be good enough for those with browsers supporting it - the rest will still have server side validation to rely on, altought the user experience won't be that great.
This example shows how it could be done (I haven't tested this very well :o):
$('form').submit(function(){
var isValid = true;
$(this).find(':input').each(function(){
var regex = new RegExp($(this).attr('data-validation-use'));
if(!regex.exec($(this).val())){
$('.validationError').append($(this).attr('data-validation-error'));
$(this).addClass('invalid');
isValid = false;
}
});
return isValid;
});
jquery validation will be best.
See the demo and code of standard jQuery validation here. jQuery Validation

Categories

Resources