HTML Validation message? - html

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.

Related

Safari HTML validation doesn't display input title when used with a pattern attribute

I'm using HTML form validation to check the user's input for various fields, like this simple ZIP code field:
<input id="zip" type="text" pattern="[0-9]{5}" title="e.g., 12345" required />
In basically all supporting browsers - Chrome, Firefox, Opera, Edge, even IE11 - if the user's input doesn't match the pattern, the text of the title attribute is displayed as a hint. In Chrome, for example, the following message is displayed:
Please match the requested format: e.g., 12345
But Safari merely says:
Match the requested format
...while ignoring the title attribute, so it doesn't actually say what the requested format is.
Is there any way to get Safari to display the title attribute, or some alternative way I can have it display a hint indicating what the requested format is?
Not exactly a fix but a work-around for this issue I found was by using the oninvalid attribute, thanks to this reply I found https://stackoverflow.com/a/12364405
I also realised that Safari does show the title tooltip but only if you hover over the input field rather than displaying it with the validation message.
Hope this answer helps.

Ungrammatical validation message for firefox

Firefox default messaging/validation message is grammatically incorrect.
Using the minlength html5 attribute Firefox is displaying the following words.
"Please use at least 3 characters (you are currently using 1 characters)."
Should say "1 character" is there a fix for this?
Html Below
<input type="text" minlength="3" />
This is currently a bug in Firefox's implementation. There's no extremely simple way to correct this that I'm aware of.
You can use setCustomValidity to call a function that will check the length of the field and return an appropriate validation error, using correct grammar.

Google Chrome input type="date"

I have almost no knowledge of web programming, but I have been tasked to solve something on my company's website. Apparently, I have an issue with browsers using HTML5 on a legacy site using type="date" and I need to find a way around it.
My site has a lot of date fields that the user must input like such:
<input type="date" name="DateStart" size="15" value="8/30/2011">
In every browser we currently use except Chrome, this works just fine. Chrome is the only browser that supplies rolling buttons to scroll through the date. What I see on the back end of this is an attempt to do this:
FormatDateTime(DateStart, 2)
I get an invalid date error which means that we cannot use Chrome to fill out this form. Is there a way around this problem?
Actually chrome's support for 'date' is broken. (See here). At least for the moment.
The use of 'date' in the HTML is absolutely fine - browser's which do not know of or support an input type are supposed to fallback to type='text'.
Currently chrome partially supports date, in a way that is essentially broken (it adds a couple of up-down buttons, but no datepicker.)
Of course you do need to bear in mind that if you are using type='date', and if the browser supports it, then you'll want to disable whatever datepicker support you'd otherwise be using.
UPDATE (6 Feb 2012):
It looks to me like this is now fixed. Chrome no longer claims to support input type='date', and does not provide the partially complete implementation.
UPDATE (17 Aug 2012):
Chrome does now have input type="date" support, and it's more functional this time.
Chrome does not have issues with date-inputs, you are using the wrong date-format, sir. Chrome isn't the only browser until today which has support for the new HTML5 inputs. Opera for example displays a dropdown with a calendar on inputs with type="date".
Also the size-attribute does not exist on HTML5-date-inputs.
The value field for the input type = input needs to be in the format yyyy-MM-dd. Check the W3 standards on this.
This means you must do something like DateTime.Now.ToString("yyyy-MM-dd"). in your code, I would suggest a custom HtmlHelper.
The format of the date in the browser is completely dependent on your system settings.
Use this date format : date("Y-m-d");

IE8 claims my page has an error, firefox doesn't, and I can't find any error. Help!

This is something of a follow-up question to my question here. You can find the HTML source in a text file here.
When I load that page in IE8, I get the "Done, but with errors on page." message in my status bar. The detail view shows
Expected identifier
sms Line: 147
Code: 0 Char: 67
and I see absolutely no problems anywhere near there. In IE8, the page is still behaving erratically w/r/t the randomly losing focus as mentioned in my other question.
When I load the same exact page in Firefox (using Firebug) the console shows no errors and the page works perfectly. Any thoughts on what's going on here? This is driving me nuts and making me want to give up on even trying to write an IE friendly page.
Edit: Thanks for all the comments! This page is written as a JSP, so I edit in Eclipse. I found an Eclipse warning about the onblur event for the username field. I switched it from
onblur="alert(document.activeElement + ' class:' + document.activeElement.class)"
to
onblur="alert(document.activeElement)"
and that made the bizarre IE page error vanish. I had been trying to give more info (namely, its CSS class) about specifically which element is stealing focus - to my own detriment, apparently, since Javascript was interpreting the '.class' part in the Java(script) sense there is no class property (I should have been using className).
And, no, the page doesn't validate. But the errors were mostly/all ones that just didn't make sense to me, such as
Line 14, Column 41: Attribute "LANGUAGE" is not a valid attribute. Did you mean "language"?
But I'm still stuck trying to figure out why, as I enter text in the username & password fields, focus randomly switches to a div (working on figuring out which div currently).
Edit 2: It's the div between the two "global nav" comments, at the very top of the body. Still no idea why it's happening, though.
The problem appears to be the line
onBlur="alert(document.activeElement + ' class:' + document.activeElement.class)"
when you take off the ".class" it loads without issue. Are you sure ".class" is valid?
Does your HTML validate?
I agree, IE does a terrible job giving developers information about page errors. I only support IE on the principle that users shouldn't have to download twenty-odd browsers to go to their favorite websites. Web developers have a responsibility to make it "just work". Browser developers have a responsibility to communicate with each other and conform to standards.
Run your javascript through JSLint. You probably have a missing semicolon somewhere or a comma at the end of an object property that shouldn't be there. Firefox is more forgiving than IE when it comes to those types of syntax errors.
Edit: The inline js in your page seems to be OK. Check the contents of qm_scripts.js.
When I remove the .class from document.activeElement.class the error goes away.
The real issue is that you need to be able to debug your JS in IE 8, correct? There is a tool for that! :)

Is there a valid way to disable autocomplete in a HTML form?

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>