HTML5-Formulare mit Polyfills – lohnt es sich?

Lesezeit: 9 Minuten

Benutzer-Avatar
Drache

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!

  • 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

Benutzer-Avatar
Alexander Farkas

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:

  1. funktioniert immer noch ohne JS
  2. 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:

  1. funktioniert immer noch ohne JS in modernen Browsern
  2. 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');
  1. 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!!!)
  2. funktioniert immer noch ohne JS in modernen Browsern
  3. moderne Browser laden nur die UI und den UI-API-Glue, aber nicht die DOM-API (valueAsNumber, valueAsDate…)

  • Danke Alexander. Ich habe letzte Woche damit verbracht, mir Webshim anzusehen – ich habe sogar ein Beispiel, das lokal läuft – tolle Arbeit und vielen Dank! Ich werde mit einem ausführlichen Formularmuster herumspielen und mehr erfahren.

    – Drache

    3. Februar 2012 um 20:02 Uhr

  • Außerdem noch eine Sache. In asp.net MVC haben wir die Möglichkeit, Datenanmerkungen für Klassen im serverseitigen Code zu definieren. Diese Anmerkungen definieren und bieten die Validierung sowohl serverseitig als auch clientseitig (über das Validierungs-Plug-in für JQuery-Formulare und “unaufdringliche Validierung”). Die meisten MVC-Entwickler sind damit verheiratet, weil es ihr Leben bei der Validierung so viel einfacher macht. Ich werde auch nach dem einfachsten Weg suchen, die 2 zu heiraten, indem ich das unauffällige Skript anpasse …

    – Drache

    3. Februar 2012 um 20:06 Uhr


  • Alexander, könnten Sie sagen, wie man das Typ-E-Mail-Popover nicht nach ein paar Sekunden verschwinden (ausblenden) lässt. das scheint das Standardverhalten zu sein, wie ändere ich es, um sichtbar zu bleiben, bis ich auf das Eingabefeld klicke. Sieht so aus, als ob es in der Javascript-Datei passiert. Also, wie man es richtig ändert.

    – krishna

    16. Juli 2014 um 3:52 Uhr


  • Danke Alexander, noch eine Frage. Ich sehe, dass die Webshims dieses dynamische Fehler-Div mit Klassen wie „ws-po-box“ erstellen, um die Fehlermeldung anzuzeigen. Sind diese Klassennamen konfigurierbar, damit ich die vorhandenen Fehlerklassennamen meiner Website angeben kann? Noch besser: Können wir die Art und Weise konfigurieren, wie Markup für diese Fehlermeldung generiert wird (der Styleguide/die Musterbibliothek meines Unternehmens schlägt einen bestimmten Markup-Stil vor)? Bitte verweisen Sie mich auf die Dokumentation, falls diese bereits vorhanden ist. Danke vielmals.

    – krishna

    24. Juli 2014 um 23:40 Uhr

  • Oh, es ist hier afarkas.github.io/webshim/demos/demos/forms.html#UI-ival. mein Fehler.

    – krishna

    11. August 2014 um 5:01 Uhr

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>

1213170cookie-checkHTML5-Formulare mit Polyfills – lohnt es sich?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy