tout d'Abord, je suis le créateur de webshims lib (un de ces polyfills, qui n'est plus entretenu). Pour répondre à ta question:

est-ce que cela vaut la peine de créer un formulaire polyfill pour un projet?

Non, c'est vraiment difficile de faire ça juste pour un projet. Eh bien, je l'ai fait, tout simplement parce que je veux utiliser les technologies modernes.

est-ce que cela vaut la peine d'utiliser un formulaire polyfill comme webshims lib pour un projet?

Oui, absolument! Et voici pourquoi:

1. Nice standardised declarative Markup API

Après, y compris webshims et le script suivant:

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

Vous pouvez simplement écrire vos widgets et vos contraintes dans votre formulaire:

<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" />

cela créera 3 widgets différents et chacun est configuré différemment. Aucun JS supplémentaire nécessaire juste standardisé, propre et lean code.

2. DOM-API standardisé

idem pour L'API DOM. Voici deux exemples: Combinaison de deux champs de date et combinaison d'un champ avec un champ de date.

3. fonctionne sans JS dans les navigateurs modernes

Dégrade gracieusement dans les vieux navigateurs et fonctionne bien dans les modernes.

4. Moins de taille de fichier dans les navigateurs modernes

Particulièrement bon pour mobile (iOS 5, Blackberry n'a pas de support pour la date par exemple)

5. Meilleur UX [la plupart du temps mobile]

meilleur UX mobile (meilleur UI input pour toucher, meilleure performance, s'adapte au système), Si vous l'utilisez: type= "email", type= "number" et type= "date" / type="range"

mais quand même, qu'en est-il de la personnalisabilité?

je suis développeur dans une plus grande agence et vous avez absolument raison la plupart des clients et la plupart des designers ne toléreront pas beaucoup de différences, mais je veux toujours utiliser les technologies modernes, ce qui signifie webshims lib peut vous donner le meilleur des deux mondes.

personnaliser la validation de la contrainte

la partie polyfilling

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

personnalisation de L'interface utilisateur pour la bulle d'erreur:

//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; 
    });
});

génère le balisage suivant:

<!-- 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>

personnaliser le style d'un champ de formulaire invalide/valide:

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

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

personnaliser le texte de la validité alerte:

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

Et maintenant, quel est le point:

1. fonctionne toujours sans JS
2. les navigateurs modernes ne chargent que le code de personnalisation (3KB min/gzippé) et les vieux navigateurs chargent l'API supplémentaire (environ 13kb min/gzip) (les formulaires comprennent beaucoup plus que la seule API de validation des contraintes, par exemple il y a aussi autofocus, placeholder, output et ainsi de suite)

et ce qui est avec votre exemple spécial, personnaliser le datefield?

Pas de problème:

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

$.webshims.polyfill('forms forms-ext');

Et ici:

1. fonctionne toujours sans JS dans les navigateurs modernes
2. les navigateurs modernes ne chargent que L'UI et la colle D'API-UI, mais pas L'API DOM-API (valueAsNumber, valueAsDate...)

Et maintenant, voici la meilleure:

//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. moins de taille de fichier et un meilleur UX pour les navigateurs mobiles (la plupart des clients et la plupart des concepteurs vous aimeront pour avoir une interface utilisateur différente dans mobile!!!)
2. fonctionne toujours sans JS dans les navigateurs modernes
3. les navigateurs modernes ne chargent que L'UI et la colle D'API-UI, mais pas L'API DOM-API (valueAsNumber, valueAsDate...)