html5 forms with polyfills - is it worth it?

Question

Despite all of the buzz around html5 forms, it seems to me like you are creating extra work, in most scenarios, by going this route.

Take, for example, a datepicker field. The native html5 implementation of this renders differently in every browser. In addition your polyfilled solution (jquery UI for instance), for a browser not supporting this feature, will also render differently.

Now, we have introduced multiple points of customization and maintenance for the same form, when we had a perfectly working and unified solution with jquery!

I'd love to hear about some real world experiences in this area, because I'm getting annoyed with all of the buzz!

Answer 1

First of all I'm the creator of webshims lib (one of those polyfills, which isn't maintained anymore). To answer your question:

Is it worth creating a forms polyfill for a project?

No, it is really hard to do this just for one project. Well, I have done it, simply because I want to use modern technologies.

Is it worth using a forms polyfill like webshims lib for a project?

Yes absolutely! And here is why:

1. Nice standardized declarative Markup API

After including webshims and scripting the following:

//polyfill forms (constraint validation) and forms-ext (date, range etc.)     $.webshims.polyfill('forms forms-ext'); 

You can simply write your widgets and your constraints into your form:

<input type="date" /> <input type="date" min="2012-10-11" max="2111-01-01" /> <input type="range" disabled /> <input type="email" required placeholder="Yo you can use a placeholder" /> 

This will create 3 different widgets and each are configured differently. No extra JS needed just standardized, clean and lean code.

2. Standardized DOM-API

Same goes to the DOM API. Here are just two examples: Combining two date fields and combining a range field with a date field.

3. works without JS in modern browsers

Degrades gracefully in old browsers and works well in modern ones.

4. Less file size in modern browsers

Especially good for mobile (iOS 5, Blackberry have support for date for example)

5. Better UX [mostly mobile]

Better mobile UX (better input UI for touch, better performance, fits to the system), if you are using it: type="email", type="number" and type="date"/type="range"

But still, what about customizability?

I'm a developer in a bigger agency and you are absolutely right most clients and most designers won't tolerate much differences, but I still want to use modern technologies, which means webshims lib can give you the best of both worlds.

Customizing the constraint validation

The polyfilling part

//polyfill constraint validation $.webshims.polyfill('forms'); 

Customizing the UI for the error-bubble:

//on DOM-ready $(function(){     $('form').bind('firstinvalid', function(e){          //show the invalid alert for first invalid element          $.webshims.validityAlert.showFor( e.target );          //prevent browser from showing native validation message          return false;      }); }); 

generates the following markup:

<!-- the JS code above will generate the following custom styleable HTML markup for the validation alert --> <span class="validity-alert-wrapper" role="alert">      <span class="validity-alert">          <span class="va-arrow"><span class="va-arrow-box"></span></span>          <span class="va-box">Error message of the current field</span>      </span>  </span> 

Customizing the style of an invalid/valid form field:

.form-ui-invalid {     border-color: red; }  .form-ui-valid {     border-color: green; } 

Customizing the text of the validity alert:

<input required data-errormessage="Hey this is required!!!" /> 

And now, what's the point:

1. still works without JS
2. modern browsers load only the customization code (3kb min/gzipped) and old browsers do load the additional API (about 13kb min/gzip) (forms include a lot more than just constraint validation API, for example there is also autofocus, placeholder, output and so on)

And what is with your special example, customizing the datefield?

No problem:

//configure webshims to use customizable widget UI in all browsers $.webshims.setOptions('forms-ext', {      replaceUI: true });  $.webshims.polyfill('forms forms-ext'); 

And also here:

1. still works without JS in modern browsers
2. modern browsers only load the UI and the UI-API glue, but not the DOM-API (valueAsNumber, valueAsDate...)

And now, here comes the best:

//configure webshims to use customizable widget UI in all non mobile browsers, but a customizable one in all desktop and all non-capable mobile browsers $.webshims.setOptions('forms-ext', {      //oh, I know this is bad browser sniffing :-(     replaceUI: !(/mobile|ipad|iphone|fennec|android/i.test(navigator.userAgent)) });  $.webshims.polyfill('forms forms-ext'); 

1. less file size and a better UX for mobile browsers (most clients and most designers will love you for having a different UI in mobile!!!)
2. still works without JS in modern browsers
3. modern browsers only load the UI and the UI-API glue, but not the DOM-API (valueAsNumber, valueAsDate...)

Answer 2

In support of Alexander's webshims answer I have done considerable research into the cross browser behaviour of the HTML5 inputs from a UX, UI and front-end perspective. My conclusion is that the only way to have prefered behaviour across devices and browsers is to use a polyfill like webshims. Much of this has to do with not being able to utilise native functionality on devices like barrel rollers for dates and numeric keypads for numbers without also having a way to support desktop browsers which do not implement those features.

Here is an analysis of how a date input behaves on different native implementations vs popular plugins:
Date input analysis - Google spreadsheet
(You can see how webshims gets the best off all implementations)

Here is an analysis of how real world input types behave across common browsers natively and with a webshim fallback:
UX analysis of HTML5 inputs with webshim fallback - Google spreadsheet

Here is the demo page used to analyse these inputs:
HTML5 inputs page demo - CodePen