Trotz all der Aufregung um HTML5-Formulare scheint es mir, als ob Sie in den meisten Szenarien zusätzliche Arbeit schaffen, wenn Sie diesen Weg gehen.
Nehmen wir zum Beispiel ein Datepicker-Feld. Die native html5-Implementierung davon wird in jedem Browser anders gerendert. Darüber hinaus wird Ihre polyfill-Lösung (z. B. jquery-Benutzeroberfläche) für einen Browser, der diese Funktion nicht unterstützt, ebenfalls anders dargestellt.
Jetzt haben wir mehrere Anpassungs- und Wartungspunkte für dasselbe Formular eingeführt, als wir mit jquery eine perfekt funktionierende und einheitliche Lösung hatten!
Ich würde gerne von einigen realen Erfahrungen in diesem Bereich hören, weil ich mich über all das Gerede ärgere!
Zunächst einmal bin ich der Schöpfer von webshims lib (eine dieser Polyfills, die nicht mehr gepflegt wird). Zur Beantwortung Ihrer Frage:
Lohnt es sich, für ein Projekt eine Polyfill-Formulare zu erstellen?
Nein, es ist wirklich schwierig, dies nur für ein Projekt zu tun. Nun, ich habe es getan, einfach weil ich moderne Technologien nutzen möchte.
Lohnt es sich, ein Formular-Polyfill wie Webshims Lib für ein Projekt zu verwenden?
Ja absolut! Und hier ist der Grund:
1. Schöne standardisierte deklarative Markup-API
Nach dem Einfügen von Webshims und dem Skripten des Folgenden:
//polyfill forms (constraint validation) and forms-ext (date, range etc.)
$.webshims.polyfill('forms forms-ext');
Sie können Ihre Widgets und Ihre Einschränkungen einfach in Ihr Formular schreiben:
<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" />
Dadurch werden 3 verschiedene Widgets erstellt, die jeweils unterschiedlich konfiguriert sind. Kein zusätzliches JS erforderlich, nur standardisierter, sauberer und schlanker Code.
2. Standardisierte DOM-API
Gleiches gilt für die DOM-API. Hier nur zwei Beispiele: Kombinieren von zwei Datumsfeldern und Kombinieren eines Bereichsfelds mit einem Datumsfeld.
3. funktioniert ohne JS in modernen Browsern
Wird in alten Browsern elegant abgebaut und funktioniert gut in modernen.
4. Weniger Dateigröße in modernen Browsern
Besonders gut für Mobilgeräte (iOS 5, Blackberry haben zum Beispiel Unterstützung für Datum)
5. Bessere UX [mostly mobile]
Bessere mobile UX (bessere Eingabe-UI für Touch, bessere Leistung, passt zum System), wenn Sie es verwenden: Typ = “E-Mail”, Typ = “Nummer” und type=”date”/type=”range”
Aber was ist mit der Anpassbarkeit?
Ich bin Entwickler in einer größeren Agentur und Sie haben absolut Recht, die meisten Kunden und die meisten Designer werden keine großen Unterschiede tolerieren, aber ich möchte trotzdem moderne Technologien verwenden, was bedeutet, dass webshims lib Ihnen das Beste aus beiden Welten bieten kann.
Anpassen der Einschränkungsvalidierung
Der Polyfilling-Teil
//polyfill constraint validation
$.webshims.polyfill('forms');
Anpassen der Benutzeroberfläche für die Fehlerblase:
//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;
});
});
erzeugt das folgende 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>
Anpassen des Stils eines ungültigen/gültigen Formularfelds:
.form-ui-invalid {
border-color: red;
}
.form-ui-valid {
border-color: green;
}
Anpassen des Textes der Gültigkeitswarnung:
<input required data-errormessage="Hey this is required!!!" />
Und jetzt, was ist der Sinn:
- funktioniert immer noch ohne JS
- Moderne Browser laden nur den Anpassungscode (3 KB min/gzipped) und alte Browser laden die zusätzliche API (ca. 13 KB min/gzip) (Formulare enthalten viel mehr als nur eine Einschränkungsvalidierungs-API, zum Beispiel gibt es auch Autofokus, Platzhalter, Ausgabe usw)
Und was ist mit Ihrem speziellen Beispiel, dem Anpassen des Datumsfelds?
Kein Problem:
//configure webshims to use customizable widget UI in all browsers
$.webshims.setOptions('forms-ext', {
replaceUI: true
});
$.webshims.polyfill('forms forms-ext');
Und auch hier:
- funktioniert immer noch ohne JS in modernen Browsern
- moderne Browser laden nur die UI und den UI-API-Glue, aber nicht die DOM-API (valueAsNumber, valueAsDate…)
Und jetzt kommt das Beste:
//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');
- geringere Dateigröße und eine bessere UX für mobile Browser (die meisten Kunden und die meisten Designer werden Sie dafür lieben, dass Sie eine andere Benutzeroberfläche auf Mobilgeräten haben!!!)
- funktioniert immer noch ohne JS in modernen Browsern
- moderne Browser laden nur die UI und den UI-API-Glue, aber nicht die DOM-API (valueAsNumber, valueAsDate…)
Zur Unterstützung von Alexanders Webshims-Antwort habe ich umfangreiche Untersuchungen zum Cross-Browser-Verhalten der HTML5-Eingaben aus UX-, UI- und Front-End-Perspektive durchgeführt. Meine Schlussfolgerung ist, dass die einzige Möglichkeit, bevorzugtes Verhalten über Geräte und Browser hinweg zu haben, darin besteht, ein Polyfill wie Webshims zu verwenden. Vieles davon hat damit zu tun, dass native Funktionen auf Geräten wie Tonnenrollen für Datumsangaben und Ziffernblöcke für Zahlen nicht genutzt werden können, ohne dass auch Desktop-Browser unterstützt werden, die diese Funktionen nicht implementieren.
Hier ist eine Analyse, wie sich eine Datumseingabe bei verschiedenen nativen Implementierungen im Vergleich zu beliebten Plugins verhält:
Analyse der Datumseingabe – Google-Tabelle
(Sie können sehen, wie Webshims das Beste aus allen Implementierungen herausholt.)
Hier ist eine Analyse, wie sich reale Eingabetypen in gängigen Browsern nativ und mit einem Webshim-Fallback verhalten:
UX-Analyse von HTML5-Eingaben mit Webshim-Fallback – Google-Tabelle
Hier ist die Demoseite, die zur Analyse dieser Eingaben verwendet wird:
Demo der HTML5-Eingabeseite – CodePen
Ich war auch skeptisch, ob es sich wirklich lohnt, durch die Polyfill-Schicht zu gehen, anstatt die reine jquery-UI zu verwenden. Nachdem ich webshims lib und HTML5 verwendet hatte, konnte ich sofort sehen, dass es viel weniger Javascript-Code gibt. Kein Validierungs-Plugin mehr erforderlich. Danke Alexander für die Erstellung und Unterstützung dieses wunderbaren Polyfill, webshims lib. Hier ist ein Beispiel für einen Ajax-Aufruf im Absenden-Klick eines Formulars.
<!DOCTYPE html>
<html>
<head>
<script src="http://code.jquery.com/jquery-1.9.1.js" type="text/javascript"></script>
<script src="http://code.jquery.com/ui/1.10.1/jquery-ui.js" type="text/javascript"></script>
<script>
// set options for html5shiv
if(!window.html5){
window.html5 = {};
}
window.html5.shivMethods = false;
</script>
<script src="webshims/js-webshim/minified/extras/modernizr-custom.js"></script>
<script src="webshims/js-webshim/minified/polyfiller.js"></script>
<script class="example">
$.webshims.setOptions({
//we do not use any DOM-/JS-APIs on DOM-ready, so we do not need to delay the ready event <- good against fouc
waitReady: false
});
//load all polyfill features
$.webshims.polyfill('forms forms-ext');
</script>
<script type="text/javascript">
$(function(){
var frm = $('#tstForm');
frm.submit(function () {
var someDate=$('#someDate').val();
alert('someDate:'+someDate);
// you can make your ajax call here.
return false;
});
});
</script>
</head>
<body>
<form id="tstForm">
Some Date:<input id="someDate" name="someDate" type="date" min="2013-01-01" max="2013-06-01" ></input>
Full Name:<input id="fullName" name="fullName" type="text" required></input>
Age:<input id="age" name="age" type="number" required min="18" max="120"></input>
<input type="submit" value="Submit"/>
</form>
</body>
</html>
Warum sollte die native HTML5-Implementierung nicht in jedem Browser anders dargestellt werden? Die einzigen Menschen, die eine Website in vielen verschiedenen Browsern betrachten, sind Webdesigner. Das Wichtigste für die Benutzerfreundlichkeit ist, dass es in einem Browser auf allen Websites gleich aussieht, nicht, dass Ihre Website in allen Browsern identisch aussieht.
– Robertc
30. Januar 2012 um 17:40 Uhr
Meiner Erfahrung nach können Designer und Kunden das nicht akzeptieren. Die meisten möchten, dass diese Elemente in ALLEN Browsern sehr genau zu ihren Themen passen.
– Drache
30. Januar 2012 um 17:44 Uhr
Ich bin mir nicht sicher, ob der Wunsch nach einem einheitlichen Erscheinungsbild für Formularelemente Sie zu einem schlechten Designer macht. Auch die Kunden wollen in der Regel das Gleiche. Ich glaube nicht, dass ich sie auch entlassen könnte.
– Drache
30. Januar 2012 um 19:17 Uhr
Ein iOS-Gerät wird die schöne Rad-Benutzeroberfläche für einen Datepicker rendern, definitiv eine enorme Verbesserung gegenüber allem, was Sie in JavaScript aufwirbeln könnten. Die meisten Mobilgeräte rendern eine benutzerdefinierte Tastatur für E-Mail- oder Nummernfelder. Lassen Sie die Geräte tun, was sie am besten können.
– Überlicht
11. November 2012 um 22:22 Uhr
Und das IOS-Rad funktioniert nicht 😉 Und in IOS heißt es, dass erforderliche Felder unterstützt werden, aber sie validieren das Formular nicht, anhaltende Kopfschmerzen!
– Drache
21. März 2013 um 20:25 Uhr