Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

HTML-Tipps für Webentwickler: Jede Woche neu

Kalender-Widgets mit purem HTML

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Unabhängig davon, ob es sich bei Ihrem Projekt um eine "große" Website handelt oder eine "kleine", Sie einen Webshop aufsetzen wollen oder einen privaten Blog betreuen – eines haben alle Webseiten gemeinsam: die Basis ist HTML. Profitieren Sie in dieser praktischen Tipps&Tricks-Sammlung von der jahrelangen Erfahrung der Trainerin Florence Maurice, die Ihnen unbekannte Features nahe bringt, zur Übersicht über die einzelnen Versionen verhilft oder oftmals nur mit kleinen, pfiffigen Hinweisen Ihren Alltag als Webdesigner und -programmierer erleichtert.
07:06
  Lesezeichen setzen

Transkript

Für den Benutzer ist es relativ mühsam, ein Datum einzugeben. Deshalb sollten Sie ihm mit dem richtigen Input-Type unter die Arme greifen. HTML 5 hat besonders viele Neuerungen für Formulare gebracht, unter anderem auch die Angabe beim Input-Feld "type=data". In HTML 5.1 ist das jetzt durch drei Angaben erweitert, nämlich "input type=week", "month" und "date-local". In diesem Dokument verwende ich diese Inputtypen: Zum einen die Klassischen aus HTML 5, sowie auch die Neuen aus HTML 5.1 wie "month", "week" und "datetime-local". Was ist der Nutzen von diesen Inputtypen? Diese sollen zweierlei Dinge bewirken. Zum einen sollen Sie dem Benutzer helfen, die entsprechende Information einzugeben, und zum anderen soll der Output vereinheitlicht werden. Sehen wir uns das einmal an. So sieht das beispielsweise im Chrom aus. Diese Felder kann ich auf zwei Arten bedienen. Zum einen, indem ich da reinklicke und dann mit den Pfeilen nach oben oder unten gehe. Es geht natürlich auch bei der Jahreszahl. Ich kann aber auch direkt hier auswählen das Datum. Genauso ist es auch bei "Date". Kann ich dann aus dem Kalender wählen. Schauen wir uns einmal "Month" an. Da kann ich als Erstes den Monat wählen und als Zweites das Jahr. Und genauso funktioniert auch die Auswahl einer Woche. Ich kann aber auch immer aus einem Kalender auswählen. Datetime hingegen funktioniert nicht. Da erhalte ich keine Unterstützung. Der Unterschied zwischen Datetime und Datetime-local ist, dass bei Datetime-local keine Angabe der Zeitzone steht. Sehen wir uns an, was dann passiert, wenn das weiter verarbeitet wird. Wähle ich hier auch mal was. Dann sehen wir die Informationen. Die werden dann zum einheitlichen Format weitergegeben. Die Anzeige dieser Widgets ist jetzt je nach Browser unterschiedlich. Sehen wir uns das Ganze einmal im Edge an. Der präsentiert das ganz anders. Wenn wir uns das mal anschauen am Beispiel Date, dann kann ich an der einen Seite den Tag wählen, in der Mitte dann den Monat und an dieser Stelle die Jahreszahl. Das sieht auf den ersten Blick so aus, als müsse man sich erst mal daran gewöhnen. Aber eigentlich ist es recht praktisch, weil man viel schneller auf die Jahreszahlen zugreifen kann als beispielsweise im Chrome. Und dann muss ich das Häkchen wählen, damit dieses Datum auch gewählt wird. Und es funktioniert dann im Prinzip auch genauso bei den Monaten oder auch bei den Wochen. Und Datetime-local funktioniert auch, und ich kann dann die Uhrzeit auch auf diese Art wählen. Ich muss immer dran denken, dann das Häkchen zu setzen. Und wenn ich das sende, dann sehe ich auf jeden Fall auch, die Übergabe ist nach demselben Prinzip, also das funktioniert einheitlich. Im Firefox wird an der Implementierung gearbeitet. Das sieht man hier. Dann stellt sich natürlich die Frage: "Wie schaut es eigentlich aus mit den mobilen Browsern?" Hier sehen Sie, wie das beispielsweise in einem mobilen Browser aussehen kann. Das ist natürlich unterschiedlich, wie das konkret umgesetzt wird, und hängt von dem System ab. Aber prinzipiell funktioniert beispielsweise "type date" sehr gut. Sieht man hier an der Unterstützung, und Datetime-local funktioniert ebenfalls sehr gut. Das heißt, wir haben bei den mobilen Browsern eine sehr gute Unterstützung. Beim Desktop ist es noch etwas durchwachsend. Beispielweise ist der Safari auch nicht dabei. Wie geht man jetzt mit dieser Situation um? Man kann beispielsweise testen, ob das funktioniert. Und wenn es nicht funktioniert, kann man irgendeine Widget nehmen. Es gibt hier eine große Anzahl von Widgets, die mit JavaScript realisiert werden, und das kann man dann einbinden für Browser, die noch nicht mit diesen neuen Input-Feldern umgehen können. Wenn man aber schon per JavaScript nachbessern muss, ist es dann nicht einfacher. Man macht das für alle Browser mit JavaScript. Dann hat man auch ein einheitliches Widget. Die Antwort darauf lautet: "Nein, denn eigentlich ist die Implementierung, die native Implementierung auf den mobilen Geräten sehr gut, das heißt, das funktioniert dort. Und gerade dort ist es ja auch furchtbar mühsam für die Benutzer, wenn es nicht funktioniert oder eben nicht so gut gemacht ist. Und das nimmt man dann den mobilen Nutzern, wenn man sagt, man macht eine einheitliche JavaScript-Lösung. Beispiele, wie man so etwas machen kann, sieht man auch hier in diesem Tool "WEBSHIMS LIB". Dieses bessert nach, wenn ein Browser etwas nicht kann. Aber sonst bleibt die native Implementierung. Ich bin gerade an dieser Stelle in einem Firefox, wo das Date-Input-Feld noch nicht funktioniert. Wenn ich aber hier reingehe, dann geht das. Wenn ich mir das Beispiel hingegen im Edge ansehe, dann sieht man deutlich, dass der weiterhin seine direkte native Umsetzung hat. Zusammengefasst in HTML 5.1 gibt es noch mehr Inputtypen für Datums- und Zeitangaben, nämlich auch "month", "week" und "datetime-local". Und prinzipiell sollten Sie diese Inputtypen verwenden, und bei Bedarf können Sie dann bei Broswern nachbessern, die es noch nicht können mit JavaScript. Ganz klassisch. Es ist aber hingegen keine gute Idee, prinzipiell für solche Funktionalität auf JavaScript zu setzen, weil die native Implementierung gerade für mobile Nutzer wesentlich besser ist.