According to this answer on Stack Overflow, we can set the accept attribute of an <input type="file" /> to filter accepted input, as follows:
accept="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/vnd.ms-excel"
However, as you can notice running the simple snippet below, Chrome 43.0.something appears to simply disregard this configuration, while it is perfectly understood by Firefox 39.0.
I considered switching to a more blunt approach, using:
accept=".xls, .xlsx"
... which works fine in Chrome but makes Firefox somewhat confused, accepting only the files using the .xlsx extension.
Considering that this is probably very common and basic, I must be missing something: where am I screwing up? How do I get a html5 file input to suggest only .xls and .xlsx files consistently across browsers?
Here's a code snippet illustrating my issue (along with a JSFiddle link in case you'd wanna fiddle with it).
Accepts application/vnd.ms-excel and the likes:<br />
<label for="file1">File input</label>
<input type="file" name="file1" accept="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/vnd.ms-excel"/>
<hr />
Accepts .xls and .xlsx:<br />
<label for="file2">File input</label>
<input type="file" name="file2" accept=".xls, .xlsx"/>
Transfer them both mime-type and extension
<input type="file" name="file2" accept="text/csv, .csv"/>
DISCLAIMER: This is not an answer by any means, but merely a note to the potential other readers trying to use this attribute in a wrong way.
On this non-official W3C reference of the accept attribute, you can find the following:
Tip: Do not use this attribute as a validation tool. File uploads should be validated on the server.
It´s not recommended to use this attribute for validation, because the users could somehow work around it and not all browsers behave the same.
First: have you definitely got an html5 doctype?
<!DOCTYPE html>
Cause if you haven't, it might not work in some places.
Second: instead of using html you could use javascript or jquery. See this question / answer: jquery - Check for file extension before uploading
Third: In my experience, some html5 stuff just doesn't work sometimes. I've no clue why but it becomes necessary to get around problems by using jquery, for example.
You should always do a server side validation anyway to make sure that what the user is uploading is in fact what you have limited it to.
Remove space in
accept=".xls, .xlsx"
to
accept=".xls,.xlsx"
Works in Chrome 69 and Firefox 61. Haven't tested it on Safari, IE and Edge yet.
Chrome is automatically adding a calendar widget for any fields that are <input type="date"> and also adds some strage date formatting to the field as well. Since the original html spec called for any input type that's not one of checkbox,radio,text,password,file etc being rendered as a normal text field this was how we were triggering our calendar widget. Is there a meta tag or some other option we can set to prevent chrome from doing this?
Screenshot (please note that this is not our code, chrome is automatically adding this):
The only way to prevent the native datepicker is not to give the input a type="date" attribute; simply use a straight type="text" input. There are some major advantages of using type="date" most notably optimized input capabilities for mobile devices. But to avoid the picker from displaying you'll have to forego those.
I discuss the advantages and disadvantages of using <input type="date"> on my blog - http://tjvantoll.com/2012/06/30/creating-a-native-html5-datepicker-with-a-fallback-to-jquery-ui/.
I need a login form where I just need to provide my username,cause it will remember my password and automatically fill in the password field (Ex. Like in gmail auth).
How could I achieve that?
thanks
Luca
A note for people to avoid banging their heads against the wall: Chrome won't save and suggest passwords on untrusted sites.
As such, if you are testing on your local server at https://localhost, and you haven't generated a valid and trusted certificate, you won't be able to test this feature of Chrome's.
This type of behavior is usually defined by the browser. However there are a few things you can do to improve this behavior.
Make sure you use descriptive names for your form
<label for="username">Username</label><input type="text" name="username" />
<label for="password">Password</label><input type="password" name="password" />
Using these names can really make a difference. I for example use the Opera browser, and in my settings, I've set a few values. For example "name", "address", "telephone number". And opera will look for fields that have equivalent names, and I can let Opera fill it in for me.
The next two things are only supported in Internet Explorer, and I would by no use advice to implement them without thinking about it
I mean, I think it's no harm implementing them. It just gives a little more support to Internet Explorer users, but I wouldn't rely on them
Also Internet Explorer supports an attribute called autocomplete, which you can control whether IO should autocomplete the input. You can use it as following
<input type="text" name="username" autocomplete="on" /> <!--Enabled-->
<input type="text" name="username" autocomplete="off" /> <!--Disabled-->
Also (an IE only feature, I think...) is the support of vCards. You can add an attribute VCARD_NAME and it lets the browser fill in the appropriate vCard value. For example
<input type="text" name="email" VCARD_NAME="vCard.Email" />
Gmail doesn't autofill your password, it is your browser that does this.
What can help is using something like LastPass but you need to leave it to the individual users whether or not they want their password remembered.
Is it possible to set the default input focus on an HTML form without using JavaScript, for example:
<html>
<form>
Input 1: <input type="text" name="textbox1"/>
<br/>
Input 2: <input type="text" name="textbox2"/>
</form>
</html>
I want to set the default focus to either of the text-boxes when the form loads without using JavaScript (as I want the behaviour to occur when a user has js disabled).
You can do it in HTML5, but otherwise, you must use JavaScript.
HTML5 allows you to add autofocus to your form element, eg:
<input type="text" name="myInput" autofocus />
This does work in browsers which support HTML5 (Or rather, browsers which support this particular part of HTML5) but as you know, not everybody can use it yet.
Something to be aware of ... if you set a focused form element, then anyone using Assisted Technology (AT) like a screen reader will need to back up to see menus and any other content that is before the focused field.
A preferred method, in my opinion , is to not set focus to any field, except a skip-link if its available. That gives them the option to skip into the pages content or read the page from the top down.
As others have said, without Javascript you can't guarantee a default field. An alternative option you might want to try, if you have multiple fields that a user might want to access is using the accesskey attribute. This will essentially mean a user can return to either of the fields instantly later during browsing, which may come in handy for users of screen readers, etc...
Wikipedias article on this subject is quite useful - http://en.wikipedia.org/wiki/Access_key
This is not possible without some form of scripting. Even Google's home page requires Javascript to focus the search field.
You might be able to use the tabindex attribute and use the lowest value on the default textbox though. Check here for browser support:
http://reference.sitepoint.com/html/object/tabindex#compatibilitysection
The site suggests that
(in almost all other cases—namely form controls and links—the tabindex has excellent support)
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>