HTML5 Forms input types, attributes and new elements – demos, tips and tricks

Forms on the web. They are literally everywhere, and there seem to really be all kind of flavors for them. From day one they have been a great mean for users to input data and information and interact with various services. And what comes with that is every implementation under the sun to offer validation for them, custom display and functionality if they aren’t native in that specific web browser, and much much more. Therefore, during the development phase of HTML5, one of the important things that have been looked into is making forms on the web evolve into what both end users and developers need to make things easier. Why would every web developer have to invent the wheel again or include tons of JavaScript code just to make something very basic like a datepicker work?

Let’s leave that behind us and explore all the new additions to forms in HTML5!

There are basically five areas of improvements when it comes to form features in HTML5:

  • New input types
  • New attributes
  • New elements
  • Validation
  • APIs, such as the File API

In this article I will cover the first three of them and what it means for you as web developer. I plan to follow up with another article on how to script forms with the new options we have, and cover validation and chosen APIs.

New input types

These are the new input types in HTML5. Some of them are directly connected to be displayed in a certain way in the web browser, where others are more there for semantic value and/or connected to validation of them. The great thing about input types too is that if it’s not supported in the web browser, it will default back to a regular <input type=”text”> element: no errors, no multiple code versions to handle.

Here are the new input types:

Gives the end user a native color picker to choose a color.
Offers a datepicker.
An element to choose both date and time.
An element to choose both date and time, with local settings support.
A field for entering e-mail address(es).
Choose a full month.
Picking a number.
Offers a slider to set to a certain value/position.
A field for search queries.
Choosing a telephone number.
Input a certain time.
Entering a URL.
Picking a specific week.


Examples of these new input types, with sample or expected value (or read out value after form submission) set in their respective value attribute:

<input type="color" value="#b97a57">
<input type="date" value="2011-06-08">
<input type="datetime" value="2011-06-09T20:35:34.32">
<input type="datetime-local" value="2011-06-09T22:41">
<input type="email" value="">
<input type="month" value="2011-06">
<input type="number" value="4">
<input type="range" value="15"> 
<!-- Note: If not set, default attribute values are min="0", max="100", step="1". -->
<input type="search" value="[Any search text]"> 
<!-- Note: In WebKit-based web browsers (Google Chrome, Safari) you can add the non-standard results attribute to get a looking glass icon to click to see the latest searches, and the attribute autosave to keep them across page loads. -->
<input type="tel" value="[Any numeric value]"> 
<!-- Note: Most web browsers seem to let through any value at this time. -->
<input type="time" value="22:38">
<input type="url" value=""> 
<!-- Note: requires a protocol like http://, ftp:// etc in the beginning. -->
<input type="week" value="2011-W24">

Demo page

You can see all of these new input types in action with their code listed below at HTML5 Forms input types demo.

New attributes

To complement the new input types, there are a number of new attributes for actions web developers often need:

An option to turn off automatic form completion of values for a field. Possible values are “on” and “off”.
Whether focus should be set to this field as soon as it has loaded.
For buttons that submit a form (e.g. <input type=”submit”>, <input type=”image”> and <button> elements) to be able to override the action attribute of the form; for instance if different buttons should submit the form to different URLs. No more JavaScript to do this!
For buttons that submit a form to be able to override the form’s specified encoding
For buttons that submit a form to be able to override the form’s method attribute, in case a button should change the method.
Append to a submit button to bypass form validation.
For buttons that submit a form to be able to override the form’s target attribute.
To connect with a <datalist> element by its id, to use its <option> elements as suggestions.
Maximum value for the value that can be put in.
Minimum value for the value that can be put in.
Allows for selection of multiple files for <input type=”file”> elements, and for multiple e-mail addresses separated by a comma.
Applies only to the <form> element, and prevents a form from being validated before submitted.
Declaring what pattern should be used for validating a field’s value, in the form of a regular expression.
Meant to be able to display a hint to the end user what to input. (Side note: I wrote a blog post discussing the desired behavior of the placeholder attribute)
If a field should be readonly.
For validation purposes, if a field is required or not.
Lets the web browser know if it should spell check the contents or not.
Possibility to control the size of each step for elements that accepts number or date input.


Examples of the new attributes:

<input type="text" autocomplete="off">
<input type="text" autofocus>
<input type="submit" formaction="" value="Save">
<input type="submit" formenctype="application/x-www-form-urlencoded" value="Save with enctype">
<input type="submit" formmethod="POST" value="Send as POST">
<input type="submit" formnovalidate value="Don't validate">
<input type="submit" formtarget="_blank" value="Post to new tab/window">
<input type="text" list="characters"> 
<!-- Note: See a complete example in the New elements section below. -->
<input type="range" max="95">
<input type="range" min="2">
<input type="file" multiple>
<form action="" method="GET" novalidate>
<input type="text" pattern="[A-Z]*"> 
<!-- Note: It is case sensitive, so you need to supply both lower- and upper-case letters if you want to allow that. -->
<input type="placeholder" name="first-name" placeholder="E.g. John Locke">
<input type="text" readonly>
<input type="text" required> 
<!-- Note: Some web browsers have to have a name attribute for this to work (this could also apply to other HTML5 Forms features, so pro tip is to always have a name attribute for form elements). -->
<input type="text" spellcheck="true"> 
<!-- Note: Has to be set to true or false, just an attribute present doesn't work -->
<input type="number" step="3">

Demo page

You can see all of these new attributes applied to form elements in the HTML5 Forms attributes demo.

New elements

Contains a number of <option> elements with values that can be used as suggestions for other form elements through the usage of the list attribute on them.
Offers a way to create a public/private key pair where the public key is sent with the form. (Ok, I’ll be honest – probably not the new element that will get you the most excited… Also it seems like Internet Explorer are not interested in implementing it either)
The meter element is for displaying values on a bar, where you can custom control min, max and assigned value. You can also specify low, high and optimum to set up different kind of areas of the bar.
Dedicated to output the result of a calculation in the page, for instance sliding a <input type=”range”> back and forth.
Meant to be used to indicate progress of any kind in a web page, for instance file upload progress.


Example code of using these elements:

Note that the value attribute is the value being read out for its connected <input> element. In some web browsers, the inner text of the <option> element, if set, overrides the value attribute; in other web browsers only the value attribute is taken into consideration. So the best way to make it work is using the value attribute for suggestions.

<input type="text" name="characters" list="data-list">
<datalist id="data-list">
    <option value="Hugo Reyes">
    <option value="Jack Shephard">
    <option value="James 'Sawyer' Ford">
    <option value="John Locke">
    <option value="Sayid Jarrah">
<keygen name="key"></keygen>

Important to note for the <output> element is that support for the JavaScript event oninput for the <form> element is required (it used to be an onforminput event on the <output> but that has now been deprecated). The code in the example below detects whether there is existing support for the oninput event, and if yes, applies an event handler that updates the value of the <output> element according to the value set for the <input type=”range”> element.

<meter min="0" max="10" value="7"></meter>

<input type="range" id="range" name="range">
<output for="range" id="output"></output>

(function () {
    var theForm = document.getElementById("the-form");
    if ("oninput" in theForm) {
        theForm.addEventListener("input", function () {
        output.value = range.value;
    }, false);
<progress max="100" value="70">70%</progress>

Demo page

All the new elements are available to test in the HTML5 Forms elements demo.

Web browser support

As you can imagine, web browser support for such a vast amount of different features is varying. Another factor that plays in is that there’s room for interpretation in the specifications how some form elements should be displayed, and the expected behavior of them. There are a few compatibility lists that I like and I recommend taking a look at:

However, I strongly urge you to test as much as possible yourself. Things are changing constantly when it comes to web browsers nowadays (about time, right?) and not all test tables will be up to date. It could also be that a web browser claims to support something when tested with feature detection, but in reality it doesn’t work. Or, it works, but the user experience is not the one you want to convey.

So code like crazy, but evaluate the result of your code and how end users will perceive it: after all, we do this to give them the best experience!

Mobile improvements

One important thing to also bear in mind is with myriad of mobile devices, tablets et al, is that while there might not necessarily be support for a certain input type, by using it, it could trigger the most appropriate keyboard layout to make inputting information as smooth as possible for the end user. This means a number keyboard layout for <input type=”number”>, URL layout for <input type=”url”> etc.

Downside: styling

While we have an abundance of new features for forms in HTML5 and CSS3 pseudo-classes for styling elements (e.g. :valid, :invalid, :required), one of the major shortcomings is that there are very few ways to style the native controls like datepicker, range, validation messages etc. And sure, we could argue that it’s great for end users if form elements look the same across all web sites, to give them the soothing calm of consistency.

But there are two important reasons why that will never suffice:

  • The styling supplied for various form elements always seem to be a bit of a low priority when they surface, and over time they get better. But many people believe that the design of form elements leave a lot to desire.
  • Web sites will always have the need to make the design consistent with the rest of the web site, for a better user experience and for branding. This is inevitable, and if we don’t provide it for them for HTML5 Form elements, they will very likely go back to using JavaScript-powered solutions for all of the above, and I don’t believe anyone really gains from that.

At the time of writing, there a few ways you can style HTML5 Form elements in WebKit, in this fashion:

/* Remove default input type="search styling */
input[type="search"] {
  -webkit-appearance: textfield; /* You could also use none */
/* Style placeholder text */
input::-webkit-input-placeholder {
    color: #ffffa2;

There are a bunch more, and you are interested, you can read up on them in Styling Form Controls Using Pseudo Classes. Do beware that this is not standard, and that they might change over time (but hey, if you have a deadline now, who cares? :-).

There have also been suggestions mentioned by Peter Gasston on how we could add some new CSS pseudo-classes to handle this. For example:

/* Note that this is not valid CSS code and won't work anywhere */
input::error {
    position: below;

Do something formtastic!

As you can see with all the new input types, attributes and elements, a lot of the things we spent countless hours on implementing before will be native in web browsers, saving us a lot of work and offering users something extremely well tested and implemented. With HTML5 really comes a revolution on the web with open standards to try and meet all the needs of developers, and it is all implemented in a very fast pace.

I’d like to urge you to use these new HTML5 Forms features, be it just for some more semantic value or for offering a lot of the new functionality as well. They are here to make things better for you, so evaluate them, learn their tricks and tweaks, and make sure to let your feedback go to web browser vendors and specification writers, so they can ensure that they will meet the needs of the development community.

Now go do something formtastic!


  • […] HTML5 Forms input types, attributes and new elements – demos, tips and tricks all these are described together with code samples and demos to see how they work in your web […]

  • realityking says:

    Small note: The input type tel has no real value sanitation according to the spec, I think it is just supposed to strip newline characters and that is it.

  • […] HTML5 Forms input types, attributes and new elements – demos, tips and tricks – Robert&#8217…. […]

  • Neovov says:

    Thanks for this post Robert,

    I have some question:
    – You wrote that autocomplete attribute takes “on” or “off” as value, does it means it doesn’t behave like other attributes like autofocus for instance? (like a regular boolean, <input type="text" required /> for HTML or <input type="text" required="required" /> for XHTML?). Why has this attribute a different behaviour?

    – I recently tried the pattern attribute (for a zipcode) and it seems that webkit doesn’t support regexp flags. Can you validate/invalidate that?

    – You wrote that input[type="search"] { -webkit-appearance: textfield; } remove default style. That’s true but it mainly allow you to style the input. Otherwise you still could try…

    – There is an equivalent of input::-webkit-input-placeholder for Firefox : input:-moz-placeholder. But it doesn’t seems to work together, you’ll have to make two rules (WTF?)

    – Will all these constraints validation work with Javascript disabled? I still remember <video controls></video > with Firefox and Javascript disabled: no controls at all (what a shame).

    – Of course, last but not least, when will WebForm 2.0 be available in Firefox 🙂 ? #troll


  • p> says:

    As soon as IE6 dies and IE7 onwards supports these tags I’ll use them. In the meantime they are unfortunately just double the work unless there’s some compat library I’m not aware of, for IE.

    Once again Microsoft is the boat anchor of the web whilst other companies are oceans ahead.

  • Robert Nyman says:


    It seems so now, yes, but perhaps there should be some kind of other character checking – i.e. numbers, + character, spaces.


    You’re welcome!

    – Regarding autocomplete, I have no idea why it is like that, but yes, the attribute has to have one of those values.
    – I don’t know about the state of regexp validation and flags in WebKit, sorry. If that’s your experience, it might be a work in progress.
    – With styling, yes you could still try, but I believe that really helps.
    – Honestly, I’m not sure about the state of that – maybe it’s about the syntax and current web browser support/implementations.
    – I hope it will all work without JavaScript, and I for one believe they should.
    – Regarding WebForms 2.0, it has been “superseded by the Forms chapter of the HTML5 specification”


    I recommend taking a look at HTML5 Cross Browser Polyfills for options on that.

  • alexander farkas says:


    autocomplete is an old attribute introduced by Microsoft. This is the reason, why it’s not a standard boolean attribute. This attribute is already used, to create custom suggest/autocomplete features (similiar to what you can do now with datalist) or for security reasons. It is supported by all browsers.

    pattern does not support regexp flags. The pattern has to match the full value and is compiled with global, ignoreCase, and multiline flags disabled. Simply go to to find or share a good RegExp for the pattern-attribute.

    JS turned off: Yes constraint validation works in Chrome, FF and Opera with JS disabled.

    pseudoselectors: see my answer above. This might be heavy, but it’s the standard.

    Webforms in FF: FF already supports a lot: Here some content attributes: required, pattern, datalist, output, keygen, [type=”email”], [type=”url”], novalidate, formnovalidate and a lot more.

  • Robert Nyman says:


    Thanks for covering for me! 🙂

    – Now that you mention it, I remember that about autocomplete.
    – With pattern, wasn’t it intended in the long run to support flags, though?

  • alexander farkas says:

    You always have to seperate non-standard selectors, because of the CSS-parsing rules. This might be a lot more work than using multiple CSS-properties, but that is the standard. BTW.: There is also a placeholder pseudoselector for IE10 (:-ms-input-placeholder).

    About FF’s HTML5 forms support. The set of supported input types by FF6 is very short, but I think the support of the hole form API is much much better, than in Opera (Opera has so many bugs, which needs to be fixed). And for me this shows, that Opera wants to show, what they have, while FF wants to create solid and good implementations.

    I think your output + input[range] example is really bad, because it creates some a11y-issues. Because this is a common example, I tried to discuss this @html5doctors and created a simple demo explaining the problems. I really would like to have some feedback.

    And here is one of my formtastic demos 🙂

  • alexander farkas says:


    pattern: From spec no. And I don’t saw a discussion about this. If you want to do such things you can use setCustomValidity. I don’t really like the API of this method, but that’s another story.

  • Robert Nyman says:


    Thanks for the demo! 🙂
    Regarding accessibility and output, though, could you humbly say that it is rather a problem of implementation, and that there could be alternatives?

    I seem to remember hearing about patterns and flags somewhere, but perhaps it was just a discussion.

  • alexander farkas says:

    *About range + output*:

    I don’t think, it is an implementation problem. From spec putput is used for the result of a calculation. If you want to make this a11y, it is wise to use a liveregion. In this case you do transform/calculate the input of the user to another state a give feedback about this transformation.

    In case of range + output: The situation is totally different. You don’t transform anything, you do repeat the input of the user. In case of [type=”range”], there might be a need to show the exact value the user has entered, but this should be only done for users not using screenreaders or similiar ATs. For a screenreader user the exact value of a type=range is absolutley clear, because the screenreader does announce the exact value.

    You wouldn’t combine one input[type=”number”] with an output. Simply because you add extra noise without giving any additional value/information to the output element.

    But you are right, if this common example stays, it will become an implementation issue. In this case should change it’s implementation advices.

  • Robert Nyman says:


    Thanks for explaining the perspective!
    Good to understand how it works and the possible problems, and it will be interesting to see what people think about this.

  • […] We can access to the list of new features (among these Websockets, that are back) here. Some examples of webforms are also provided, and an article about fake 3D using CSS transforms. Like this:LikeBe […]

  • Neovov says:

    Thanks Robert & Alexander! seems very useful.
    I didn’t know we have to separate non-standard selectors, I rarely use some of them. Good to know!
    Good to know too how pattern’s regexp are compiled.

    I’m sorry about FF, it was a #troll question for Robert who’s now working for Mozilla. BTW, I’m happy to read that FF has started to ship WebForms support. I’m aware that every browser’s vendor has different priority and I believe none of them has a good support since the spec isn’t complete (I don’t really know the status of WebForms).

    Your discussion about a11y is very interesting, what is the status of the a11y working group about WebForms?

    About that, I recently used an <input type="month" /> and was scared that we can’t change the date’s format or worst: that the format doesn’t match to the browser’s locale. Maybe can you enlight me?


  • alexander farkas says:

    locale format of month/date etc.: The format of the value is always the same, but the format shown to the user should switch to the user’s locale. Currently this is only implemented for type=”number” in Chrome.

    State of the spec: The main parts of the forms specification are quiet stable. Due to the fact, that FF4 has implemented a lot and IE10 will implement a lot of the forms chapter. You can expect, that there will be additions, but no big changes to the current APIs.

    About my Opera bashing: As i started my webshims lib project about 9-10 month ago, I found a lot of bugs in Webkit and in Opera. I did report those bugs. And in case of Webkit all non-UI bugs, where fixed extremley fast. In case of Opera, they have decided to implement the input[type=”color”] (a feature, which is not existent in any other browser), but they haven’t fixed any of those real bugs since then. So I do question their priority, why do they implement stuff, which can’t be used, but are not able to fix buggy features, which are already implemented the right way in other browsers. And those bugs are critical. For example: If a user trys to submit an invalid form, Opera will fire a submit event. (But we all know, you can not submit an invalid form. If you are using AJAX the hole constraint validation will fail.)

  • Robert Nyman says:


    Thanks for clarifying!

  • Neovov says:

    Thanks Alexander.

  • […] Robert Nyman, a Technical Evangelist for Mozilla, has a very thorough post examining all the new input types, attributes and elements for HTML5 forms. Even better, Nyman has plenty of examples, demos and sample code to show how each element works. […]

  • […] Robert Nyman, a Technical Evangelist for Mozilla, has a really consummate post examining all a new submit types, attributes and elements for HTML5 forms. Even better, Nyman has copiousness of examples, demos and representation formula to uncover how […]

  • […] Robert Nyman, a Technical Evangelist for Mozilla, has a very thorough post examining all the new input types, attributes and elements for HTML5 forms. Even better, Nyman has plenty of examples, demos and sample code to show how each element works. […]

  • […] HTML5 Forms input types, attributes and new elements – demos, tips and tricks – Robert'… (tags: html5 forms tips demo sample) […]

  • Andy says:

    Now it’s up to the BROWSER to decide a valid email regex? That’s absolutely terrible. HTML5 needs to stop going into these realms.

  • Robert Nyman says:


    Ehm, no. This is something being standardized. I recommend reading I Knew How To Validate An Email Address Until I Read The RFC.

  • Stomme poes says:

    I generally like the new form input types. They seem to generally be one of the safer-to-use new things from HTML5. Still, plenty of kvetches:

    The color input type is not only completely useless, it’s also completely useless. Someone enlighten me.
    I have tried CSS colour names (such as “red”), have tried to use the keyboard, and everything basically fails except 6-digit hex and a mouse (I expect the keyboard bugs to get fixed eventually).

    Imagine: you are not using one of the fancy new HTML5 browsers, and you are not a web nerd. The input type=color defaults to a text input. Unbeknownst to you, the soccer mom, you are required to type in a 6-digit hexadecimal number in order to fill in a colour. Right. Cause you’re definitely going to go look that up somewhere instead of abandoning the form.
    I really like that the rest default to… the default, text. But with color it doesn’t help anyone. If we’re offering colour as an option on our forms and we want to validate it, it’s much simpler to avoid the color-type and just use something else. A select or a set of radio buttons or something.

    Color-type also makes no sense with e-commerce, where often such an input would seem wonderful… except your product is only available in limited colours and with whichever colour names the manufacturer has chosen. I heard this input was for something to do with online photoshopping or something. I’m confused why someone would go to the trouble of creating an entirely new input for something so incredibly specialised while plenty of other obscure possible input types haven’t seen the light of day (so I suspect some other reason was for this input type. Would love to hear what exactly).

    Error messages are in the language set by the browser, which may not be the language of the user or the site (ever use a computer in a hotel in a foreign country?). Using title attributes gives a nice bit of confusion as both messages appear (in Opera on Linux, the error messages are in strange places and often unreadable as they go offscreen). Though possibly this will not be the final setup. Also error messages in title attributes sucks when you’re using a screen reader, so I won’t use them for now (I read recently that titles were *recommended* for a particular input type’s error message, but don’t remember which type that was).

    The “novalidate” attribute (on an input; haven’t checked on a form) seems to only check for “required” but cannot be used to turn off “pattern” (say you wanted to use pattern for :valid/:invalid styling, or to send information to a validating Javascript (to avoid regexen twice), but didn’t want the browser’s error message to appear… looks like a no).
    Autocomplete, autofocus, spellcheck: I used to be able to turn these off in my browsers by blocking Javascript. I keep hearing (for example on Mark Pilgim’s rather nice HTML5 site) that these HTML5 versions are better because users can turn them off. Really? How?
    And spellcheck… hotel computer problem strikes again. These things belong to the user, not the author. Let US turn them on and off please.

    The output element seems to need Javascript to work. So I would encourage that the element only gets added by Javascript itself anyway (we of course go further than just *preaching* about progressive enhancement don’t we).
    I’m glad for the link to Too Much Output example, thanks.

    The IE team is probably correct in not supporting keygen. I read the head of the IE team’s reasons and they made sense to me.

    At least in Opera, I notice between Linux and Windows a different order of validation. On Linux, HTML5 validation happens before the submit event. On Windows, it comes afterwards. It may ultimately not matter, but consistency across any particular browser, let alone cross-browser, would be kinda nice. Not that I expect that yet for something still in draft, but all this has been a rant about draft specs anyway. : )

    Quibbles aside, playing with these on non-production sites has been fun.

  • Robert Nyman says:

    Stomme poes,

    When it comes to color inputs for web browsers that don’t have native support for it, I would recommend using a polyfill to make sure it works as expected in them too.

    I agree about error messages, that is indeed a problem.

    Interesting input about spellcheck and the related attributes!

    If it requires JavaScript, generally JavaScript should generate it, I think.

    With keygen, I think it’s more about that if you have a specification, everyone need to support the same set of it – otherwise it renders the specification more or less useless.

    I believe validation events should be consistent, no matter the platform.

  • alexander farkas says:

    @ Stomme poes

    error messages:
    You can change the errormessages using setCustomValidity (but this API sucks for this purpose). FF has a really nice content attribute for this: ‘-moz-errormessage’. And my hope is, that something similiar will be added to the specification. (BTW.: webshims lib has a configuration option to use -moz-errormessage or data-errormessage in all browsers).

    Titles are recommended in conjunction with the pattern attribute and there is no big problem in conjunction with screenreaders. If you use a label, the label is used for the a11y name and the title for the a11y description. And the a11y description is only read, if the sr-user wants to or the screenreader is configured this way. Only if you ommit the label, the title is used for the a11y name.

    novalidate is not allowed on an input element, it is only allowed on form. There is another similiar attribute called formnovalidate for submit-buttons. If you don’t want to have a single input validated simply remove the constraints (i.e. remove pattern and change type=”email” to “text”). I don’t really see a problem, here.

    form submission (order):
    Order of interactive constraint validation is specified in HTML. Opera doesn’t really care about this (in Chrome and FF everything is fine). In case of an invalid form, there should be no submit event, because there is nothing to submit. And order is really cruical here. Think of an AJAX-Form. You should intercept only the submit event and know, that everything is fine, with the form. In Opera this doesn’t work.

    To use this as an advertisement. There is no problem to use most of the new form features right now. If you have a bug or only partial support in a modern browser or simply need to also support old browsers, simply drop in webshims lib and everything will work as specified. The best thing is, that modern browsers, won’t have to load the fix/polyfill scripts. BTW: I have updated my formtastic demo

  • Robert Nyman says:


    Thanks for adding your thoughts!

  • […] And a more in depth (and current) look at form elements. […]

  • […] requires a protocol like http://, ftp:// etc in the […]

  • Robert says:

    “I plan to follow up with another article on how to script forms with the new options we have, and cover validation and chosen APIs”


  • Robert Nyman says:


    When I get the time… 🙂

  • […] a vaguely connected note i found this: HTML 5 form stuffs which made me ‘oooo’ and ‘aaahh’ somewhat. The web future is looking very […]

  • Rob says:

    If you want to add …

    ‘data-errormessage='{“typeMismatch”: “Please enter a valid email address”}’

    …to an email field ?

    I’m looking to do so either with jQuery or (vb). I’ve tried but I can’t quite get it right.

    I’ve added data-dependent-validation=”email” fine, but the above is proving to be more tricky, due to {} and ” present.
    I did this using

    txt_Email.Attributes.Add(“data-dependent-validation”, “email”)

    Hope someone can help.

  • Robert Nyman says:


    Not sure about that environment, but perhaps my slides helps with how you customize form messages.

  • ??????. ? ???? ???? ??????
    ????? ?????? ??????

  • Abdul says:

    Is there any native HTML 5 validation for input type=file?. I know there is an “accept” attribute but this will not alert user with some message.

  • Jason says:

    Is there anyway to have a button invoke the HTML spellcheck? I know that IE 11 does it as you type, but we are needing to spellcheck numerous fields after the fact. Any help would be appreciated.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.