I have used HTML in my new project and seems pretty nice to use some of the new features. However there is a few things that are iffy and I can get them to work. For example if I use pattern attribute for my field validation error message isn't showing in all browsers. I read few blogs but all of them are too old and I'm not sure which of these problems are fixed. Here is my example:
<input type="text" name="frm_field1" id="frm_field1" style="width:50px" pattern="^/d{1,3}$" title="Numeric values up to 3 digits." x-moz-errormessage="Numeric values up to 3 digits allowed." />
The code above will output the error message in Firefox but won't output anything in Chrome, Safari, and IE. I'm wondering if this problem can be fixed some how?
So far I couldn't get this error message to show in all browsers. My field is not required and validation is triggered only if value is in the field. If anyone knows the way to fix this problem please let me know.
It's because you're using a prefix specific to firefox x-moz-errormessage
There is no equivalent thing for webkit (chrome) but you might want to look at setCustomValidity
You can also preferably try using javascript to validate your form instead.
I have a page in XPages that I use to open and edit a document. There are two ways to open a document in edit-mode: first in read-mode then click a button to put it in edit-mode, or open it directly in edit-mode. Both work in all browsers, yet IE seems to handle both cases differently. We found this out when working with the SWING API.
Opening directly in edit-mode in IE (8/9/10) works, via read-mode to edit-mode doesn't. What we found is that the internal representation of a textarea field differs: when opened in edit-mode, there are more properties, but most importantly, the return+linefeeds are correctly set in both the value and the innerText property.
The button just contains a simple Change Mode action.
Has anyone heard of this anomaly? And does someone know what we did wrong?
PS I'll try to build a simple XPage that shows this behaviour more clearly tomorrow.
For IE switching from read to edit mode, you need a full page refresh
I would like to do validate elements WITHOUT using any validation plugin. To start with, I defined:
<input type='number' required="required" id='amt_elmt' name='amt_elmt' />
But I can still type any text in this control (I expected only number can be typed inside it); it accepts blank value also.
What additional code might be required?
as others have mentioned Forms 2.0 or the new HTML5 input types are not supported by all browsers (see this link).
I recently answered another question dealing with the HTML 5 form elements. None of my desktop browsers (FF, Chrome, IE) or my mobile browsers (FF, Android default browser) attempted to validate that I was using numbers, or restricted it to numbers.
Your best bet is a javascript client side validations like jquery.validate or any other number of libraries to accomplish validation.
Edit: The link is to Microsoft's validation library that comes with Visual Studio but you can download it from there website and it works quite well. I can post code on how to use it if you need it
Edit2: Codez http://jsfiddle.net/qxsS8/
Number is an HTML5 input type. This is not yet correctly supported by all browsers, in most browsers you will be able to input anything.
If you want to block anything but numbers while users are typing you are going to need JavaScript on key presses.
If you want to validate after posting if only numbers are used you can use either JavaScript or PHP for this.
Add Javascript event handlers for the events you want to handle (i.e. onkydown, onkeyup, ...). In those functions you can access the value of the input and remove the chars you don't want.
You could use standard HTML5 form validation. Then to support older browsers use this Library:
https://github.com/ericelliott/h5Validate
This will use JavaScript to add support.
All you need to add into your page is the following code:
<script src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.1.min.js"></script>
<script src="jquery.h5validate.js"></script> // You will need to host this somewhere
<script>
$(function () {
$('form').h5Validate();
});
</script>
It works across:
Desktop: IE 9, 8, 7, 6, Chrome, Firefox, Safari, and Opera. Tested on Windows 7 and Mac.
Mobile: iPhone, Android, Palm WebOS
Finally I found out that using javascript (and maybe jquery) is very flexible.
(No dependency, no third-party error, which is hard to solve for the programmer, who does not know plugin's logic).
link to "javascript only form validation tutorial"
This link proved to be very useful.
This may be helpful to others, hence posting as a separate answer to my own question.
Hello kind people of the internet,
I've been hacking at this for a while...and have seen several similar postings, but I can't seem to figure this out:
The HTML5 input field validation CSS works in Firefox, Chrome...but alas, not in IE8...and much of my target audience will be using IE8.
...and yes: I'm using Modernizr, and I used Initializr to get the page template and CSS...I'm a bit confused why I can't get things working properly in IE8.
Here's a link to my test page:
Test html5 page
The input field is red before proper entry, then validation simply turns green when input a valid account number, such as:
50011111111
The HTML5 code is as follows:
<label for="account">Account Number: </label>
<input id="account" name="inputAccount"
placeholder="input billing account number"
pattern="/(^500)|^\d{11}"
required
autofocus
type="text"/>
Any suggestions on what is probably a fairly simple thing to fix would be mucho appreciated!
IE just ignors HTML5 elements because it dosen't know about them. From the Modernizr docs
Modernizr runs through a little loop in JavaScript to enable the
various elements from HTML5 (as well as abbr) for styling in Internet
Explorer. Note that this does not mean it suddenly makes IE support
the Audio or Video element, it just means that you can use section
instead of div and style them in CSS.
What this says is that Modernizr will tell IE about the new tags in HTML5 so that you can use CSS on them, but dosen't actually make them do anything. Note too that Modernizr dosen't add default styles for the elements, so they recommend you use an HTML5 CSS reset that makes <section> tags display: block; for example.
With respect to your form validation topek was correct in explaining that Modernizr only detects browser capability, it dosen't actually do anything about it. The proccess behind Modernizr is that you use the built-in yepnope testing feature to see if the user's browser can do 'x' (in this case form validation) and then conditionally and asynchronously load a script or style to "polyfill" (a polite way of saying 'use javascript to mimic native behaviour) for it.
In your case, you will want to use Modernizr.load() to test for Modernizr.input.required and probably Modernizr.input.autofocus too, like this:
//the modernizr conditional load function
Modernizr.load({
//specify the tests, refer to the Modernizr docs for object names
test: Modernizr.input.required && Modernizr.input.placeholder,
//specify what to do if the browser fails the test, can be a function
nope: 'path/to/polyfill/script',
//sometimes you need to run some JS to init that script
complete: function(){ polyfillinitorwhatever(); }
});
And there you go, a pretty stripped-down Modernizr.load. While I find their docs meandering, they actually are very good. Every time I've had a problem and tweeted at Paul Irish, he's sent back a link to the docs where I actually did find my answer upon closer inspection.
Validation is one of the most complex HTML5 features for the browser makers to implement as a standard. While I really like it's simplicity, I've been continuing to use jQuery.validate in all cases except if the user has Chrome or Opera - the FF native validate is weak still. I'd recommend you stick with jQuery for now.
I recently found a new plugin jquery.h5form.
Using this, form validation, like in Opera, will be enabled in all browsers, even IE8.
I think, what you are still missing, is a html5 polyfill for the field validation. You could use for example: http://ericleads.com/h5validate/
More polyfills can be found under: https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills
IE8 does not support all, if any, HTML5 elements. You need to have an addon for html5 to work. One addon is modernizer
List of browsers with their score/compatibility in HTML5
When using the xhtml1-transitional.dtd doctype, collecting a credit card number with the following HTML
<input type="text" id="cardNumber" name="cardNumber" autocomplete='off'/>
will flag a warning on the W3C validator:
there is no attribute "autocomplete".
Is there a standards-compliant way to disable browser auto-complete on sensitive fields in a form?
Here is a good article from the MDC which explains the problems (and solutions) to form autocompletion.
Microsoft has published something similar here, as well.
To be honest, if this is something important to your users, 'breaking' standards in this way seems appropriate. For example, Amazon uses the 'autocomplete' attribute quite a bit, and it seems to work well.
If you want to remove the warning entirely, you can use JavaScript to apply the attribute to browsers that support it (IE and Firefox are the important browsers) using someForm.setAttribute( "autocomplete", "off" ); someFormElm.setAttribute( "autocomplete", "off" );
Finally, if your site is using HTTPS, IE automatically turns off autocompletion (as do some other browsers, as far as I know).
Update
As this answer still gets quite a few upvotes, I just wanted to point out that in HTML5, you can use the 'autocomplete' attribute on your form element. See the documentation on W3C for it.
I would be very surprised if W3C would have proposed a way that would work with (X)HTML4. The autocomplete feature is entirely browser-based, and was introduced during the last years (well after the HTML4 standard was written).
Wouldn't be surprised if HTML5 would have one, though.
Edit: As I thought, HTML5 does have that feature. To define your page as HTML5, use the following doctype (i.e: put this as the very first text in your source code). Note that not all browsers support this standard, as it's still in draft-form.
<!DOCTYPE html>
HTML 4: No
HTML 5: Yes
The autocomplete attribute is an enumerated attribute. The attribute
has two states. The on keyword maps to the on state, and the off
keyword maps to the off state. The attribute may also be omitted. The
missing value default is the on state. The off state indicates that by
default, form controls in the form will have their autofill field name
set to off; the on state indicates that by default, form controls in
the form will have their autofill field name set to "on".
Reference: W3
No, but browser auto-complete is often triggered by the field having the same name attribute as fields that were previously filled out. If you could rig up a clever way to have a randomized field name, autocomplete wouldn't be able to pull any previously entered values for the field.
If you were to give an input field a name like "email_<?= randomNumber() ?>", and then have the script that receives this data loop through the POST or GET variables looking for something matching the pattern "email_[some number]", you could pull this off, and this would have (practically) guaranteed success, regardless of browser.
No, a good article is here in Mozila Wiki.
I would continue to use the invalid attribute. I think this is where pragmatism should win over validating.
How about setting it with JavaScript?
var e = document.getElementById('cardNumber');
e.autocomplete = 'off'; // Maybe should be false
It's not perfect, but your HTML will be valid.
I suggest catching all 4 types of input:
$('form,input,select,textarea').attr("autocomplete", "off");
Reference:
http://www.w3.org/Submission/web-forms2/#the-autocomplete
http://dev.w3.org/html5/markup/input.html
If you use jQuery, you can do something like that :
$(document).ready(function(){$("input.autocompleteOff").attr("autocomplete","off");});
and use the autocompleteOff class where you want :
<input type="text" name="fieldName" id="fieldId" class="firstCSSClass otherCSSClass autocompleteOff" />
If you want ALL your input to be autocomplete=off, you can simply use that :
$(document).ready(function(){$("input").attr("autocomplete","off");});
Another way - which will also help with security is to call the input box something different every time you display it: just like a captha. That way, the session can read the one-time only input and Auto-Complete has nothing to go on.
Just a point regarding rmeador's question of whether you should be interfering with the browser experience: We develop Contact Management & CRM systems, and when you are typing other people's data into a form you don't want it constantly suggesting your own details.
This works for our needs, but then we have the luxury of telling users to get a decent browser:)
autocomplete='off'
autocomplete="off" this should fix the issue for all modern browsers.
<form name="form1" id="form1" method="post" autocomplete="off"
action="http://www.example.com/form.cgi">
[...]
</form>
In current versions of Gecko browsers, the autocomplete attribute works perfectly. For earlier versions, going back to Netscape 6.2, it worked with the exception for forms with "Address" and "Name"
Update
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"
Since this random value is not a valid one, the browser will give up.
Documetation
Using a random 'name' attribute works for me.
I reset the name attribute when sending the form so you can still access it by name when the form is sent. (using the id attribute to store the name)
Note that there's some confusion about location of the autocomplete attribute. It can be applied either to the whole FORM tag or to individual INPUT tags, and this wasn't really standardized before HTML5 (that explicitly allows both locations). Older docs most notably this Mozilla article only mentions FORM tag. At the same time some security scanners will only look for autocomplete in INPUT tag and complain if it's missing (even if it is in the parent FORM). A more detailed analysis of this mess is posted here: Confusion over AUTOCOMPLETE=OFF attributes in HTML forms.
Not ideal, but you could change the id and name of the textbox each time you render it - you'd have to track it server side too so you could get the data out.
Not sure if this will work or not, was just a thought.
I think there's a simpler way.
Create a hidden input with a random name (via javascript) and set the username to that. Repeat with the password. This way your backend script knows exactly what the appropriate field name is, while keeping autocomplete in the dark.
I'm probably wrong, but it's just an idea.
if (document.getElementsByTagName) {
var inputElements = document.getElementsByTagName("input");
for (i=0; inputElements[i]; i++) {
if (inputElements[i].className && (inputElements[i].className.indexOf("disableAutoComplete") != -1)) {
inputElements[i].setAttribute("autocomplete","off");
}
}
}
I MADE THIS WORK IN 2020!
I basically create a css class that applies -webkit-text-security to my inputs.
Here's the link to a more recent discussion:
https://stackoverflow.com/a/64471795/8754782
This solution works with me:
$('form,input,select,textarea').attr("autocomplete", "nope");
if you want use autofill in this region: add autocomplete="false" in element
ex:
<input id="search" name="search" type="text" placeholder="Name or Code" autcomplete="false">
Valid autocomplete off
<script type="text/javascript">
/* <![CDATA[ */
document.write('<input type="text" id="cardNumber" name="cardNumber" autocom'+'plete="off"/>');
/* ]]> */
</script>