Die neuen Formularelemente in HTML5 - renephoenix.de

renephoenix.de

Die neuen Formularelemente in HTML5

Zu HTML5 ist nun in der Woche der mittlerweile fünfte Entwurf veröffentlicht worden. Zu den Veränderungen hatte ich mich bereits schon einmal ausgelassen. Heute nun konkret zum Schwerpunkt der neuen Typen von Eingabefeldern bei Formularen.

Bis zur aktuellen Version von HTML wurden Eingabefelder rein funktional unterschieden, dazu gab es folgende:

  • hidden
  • text (standard)
  • password
  • radio / checkbox
  • submit / reset
  • image / button
  • file
  • zusätzlich die HTML-Elemente select, button und textarea


Diesen Ansatz hat man nun aufgebohrt und so hat man vor allem Zeitangaben integriert, konkret die folgenden zwölf:

  • search
  • url / email
  • datetime / date / month / week / time / datetime-local
  • number / range
  • color


Wie das aussehen kann, zeigt bereits Opera in der 9er Version seines Browsers. Mit Ausnahme von color und email werden bereits alle Elemente unterstützt. Besonders interessant finde ich das Datumsfeld:

include{standard}(9710).

Zusätzlich gibt es die Attribute min, max und step. In diesem Falle war das Minimum auf den 17.2. eben eingestellt.

Beim Absenden eines datetime-Eingabefeldes  erhält man eine Zeichenfolge in diesem Schema:

2009-02-25T15:04Z

Schön sieht es nicht aus, dafür wenigstens international (das Problem sind ansonsten die Amis, die Tag und Monat vertauschen). date und time funktionieren synchron mit dem jeweiligen Teil. Unter month versteht man allerdings nicht den Monat an sich, sondern eine Monatsangabe mit Jahr. week gibt nach dem Jahr die Kalenderwoche an.

Mit url listet Opera im Moment die letzten aufgerufenen Seiten auf (vielleicht auch die Lesezeichen?).

Bei email kann man das Attribut multiple anhängen — falls mehrere gültige Adressen eingeben werden dürfen. Ansonsten scheint dieser Typ noch nicht implementiert zu sein (oder vielleicht sehe ich es auch nicht und es ist an das interne E-Mail-Programm gekoppelt)

search habe ich nicht verstanden. Soll das lediglich für das Stylesheet gut sein, um dem Feld eine Lupe als Hintergrundbild zuzuweisen?

Die number ist klar: ein Textfeld für Zahlen. Gebrochene und negative Zahlen sind grundsätzlich auch möglich, min, max und step gilt entsprechend.

Und range. Es ist weiteres Feld für Zahlen, bei dem Browser ein geeignetes Steuerelement auswählen darf. Opera implemtiert es im Moment als Schieberegler, denkbar wäre (siehe erster Kommentar) auch ein Drehregler. Ich hätte dafür schon lieber die in der Softwaretechnik etablierten Steuerelemente übernommen (type=slider). Etwas irreführend ist der Begriff range allerdings: es geht nicht um die Auswahl eines Bereiches, sondern man wählt stets aus einem Bereich aus. (Ja, Usabilitytechnisch sollte man sich an der Opera-Implemantation nicht stören lassen, daß der gewählte Wert nirgends angezeigt wird).

color ist zum Picken einer Farbe innerhalb des RGB-Farbmodells gedacht. Leider ist das noch nicht bei Opera implementiert.

Auch wenn diese Möglichkeiten durchaus nett gedacht sind, an der Praxisauglichkeit habe ich noch einige Bauchschmerzen:

  • Diese neuen Elemente sind paraktisch gesehen nur Beispiele. Und wo sollten solche Beispiele in grundlegenden Standards eigentlich beginnen oder enden?
  • Im Standard konnte ich nicht entnehmen, ob Sekunden mit zur Zeit gehören. Opera ignoriert diese zunächst. Es gibt leider kein Attribut zum Einstellen des Formats. Hier hätte man synchron zur PHP-Funktion date() ein Schema mit übergeben können.
  • Für wiederkehrende Termine (z.B. Terminauswahl bei Sprechstunden) ist das datetime noch nicht ausgelegt. Das gilt auch für eine Hand voll festgelegter Termine. Oder vielleicht den Ausschluß mancher Feiertage.
  • Was sollte man tun, wenn die konkret gestellte Anforderung sich nicht mit einem der Kalendervarianten umsetzen läßt? Eine JavaScript-Prüfung beim Ändern des Wertes ist suboptimal: ein Termin würde dann trotzdem angeboten werden, für den man nach Auswahl dann getadelt wird. Also wäre das Fallback-Szenario wieder text — und man baut mit JavaScript wieder eigene Kalender. Und wenn dieser Effekt eintritt, kann man sich das Kapitel eigentlich schenken.
  • Rückwärtskompatibität zu Browsern, die das Attribut nicht verstehen, ist zwar theoretisch möglich: sie zeigen ein Textfeld an. Aber da gebe ich in der Regel ein Datum so ein, wie ich es per Hand schreibe: »Tag.Monat.Jahr«. Man müßte im Zweifelsfall also nach beiden Schemen prüfen.
  • Eine browserseitige Prüfung neigt möglicherweise dazu, die serverseitige Prüfung zu vernachlässigen. Das ist zwar kein wirklicher Grund, ich fürchte nur die Praxis von »es muß alles ganz schnell gehen«.


Mein Fazit: Diese Formularelemente sind sicher eine schöne Idee und Opera gibt dazu bereits schon einen guten Einblick über die Möglichkeiten (ohne hätte ich das Urteil gar nicht fällen können). Allerdings machen solche spezifischen Formularfelder nur dann einen Sinn, wenn ich sie vollständig einsetzen kann. Das trifft bei email und url soweit zu. Bei Zahlen sowie Datums- und Zeitangaben können diese praktischen Anforderungen dafür ins Undendliche gehen.

Zum Testen und Anschauen der neuen Elemente, habe ich eine kleine Demonstrationsseite gebastelt: Übersicht der neuen HTML5-Formularelemente (bitte mit Opera 9 anschauen)

Siehe auch: Peter Kröner, webkrauts, yatil, Tobias Otte

Bisherige Kommentare (9)

Kommentar von wrtlprnft

E-Mail ist nicht implementiert, auch wenn man (wie ich) den internen Mailclient benutzt.

»slider« ist ein unpraktischer Name, weil er auch bestimmt, wie das Element dargestellt werden muss. Manche Browser könnten für »range« vielleicht auch so ein drehknopfförmiges Teil anbieten oder für Blinde etwas ganz anderes. In HTML soll schließlich stehen, was ein Element repräsentiert, nicht wie es dargestellt wird.

Den Fehler gibt es schon viel zu deutlich bei »select« (hast du in deiner Auflistung oben übrigens vergessen) und »radiobuttons/checkboxes« sie haben die selbe Funktion, schauen aber anders aus.

Der »search«-Typ ist anscheinend — wie <a type=»search«> — dafür gedacht, dass Browser das Suchfeld automatisch erkennen können (bestimmt nützlich für Blinde und der Browser kann auch automatisch anbieten, die Seite zu seiner eigenen Suchfunktion hinzuzufügen, siehe http://en.wikipedia.org/wiki/OpenSearch )

Kommentar von René

select ist zwar ein Formularelement, wird aber nicht über input type= realisiert. Also kein Eingabefeld, sondern ein Auswahlfeld.

ok@search. Da gehe ich ja noch durchaus mit.

zu slider/range: Du hast natürlich Recht, das Aussehen ist nicht festgelegt. Man überläßt es dem Browser. Allerdings benötigen unterschiedliche Steuerelemente auch unterschiedlich viel Platz. Wenn ich ein Formular konstruiere und beispielsweise drei (semantisch) zugehörige Drehregler nebeneinander positioniere, dann würde es mit Schiebereglern den zur Verfügung stehenden Platz sprengen. Und dann helfen auch keine Breiten- und Höhenangaben im CSS. Im umgekehrten Fall hätte man dann eierförmige Drehregler ;-)

Daß es heute select / radio bzw. select multiple / checkbox ist meiner Meinung auch sinnvoll. Mein neues Formular auf der Startseite der zweitwohnsitzsteuer würde als radio den Rahmen sprengen. Das ändert aber nichts daran, daß beide Elemente für Blinde gleich aussehen können.

Würden wir allerdings es wirklich dem Browser überlassen, bräuchten wie auch kein range, sondern der Browser könnte bereits number so darstellen, vorausgesetzt min/max/step sind gegeben.

Was UTF-8 angeht: ja, es wird in absehbarer Zeit eine Generalüberholung geben. Dann werde ich es berücksichtigen, an diesen Skripten möchte ich nicht mehr viel ummodeln ;)

Kommentar von wrtlprnft

Den Unterschied zwischen number und range sehe ich darin, dass man bei number eine exakte Zahl eingibt, die man auch sieht, während man range eher nach Gefühl geht und der Nutzer mit der genauen Zahl nicht unbedingt in Berührung kommen muss (»Wie viele Eier möchten Sie bestellen?« vs. »Wie hart sollen Ihre Eier sein?«, blödes Beispiel).

Die Dimensionen sind natürlich problematisch, aber das haben viele Formularelemente bereits jetzt an sich (wo steht, dass ein type=»file«-Feld ein Inputfeld ist mit einem Knopf daneben? Es könnte ja auch an der Stelle bereits ein vollständiger Filebrowser sein). Leider müssen da die Browser ständig voneinander abschauen, um nicht vollständiges Chaos anzurichten.

Kommentar von René

@range: da haben ja die ganzen Hot-or-Not-Portale ein neues Spielzeug ;-)

Was den Datentyp file angeht, da hast du wohl recht. So exakt ist es in der Spezifikation nicht beschrieben:

This control type allows the user to select files so that their contents may be submitted with a form. The INPUT element is used to create a file select control.

Interessant ist, daß mit HTML5 das Attribut multiple dazukommt. Also: mehrere Dateien in einem Formular. Das ist durchaus eine wirklich wichtige Erweiterung.

Kommentar von wrtlprnft

Mehrere Dateien sind echt sinnvoll, man sieht ja recht oft Seiten, die »vorsichtshalber« einfach zehn file-inputs untereinander haben, damit man mehrere Dateien hochladen kann. Und dann könnte das Opera ja so ähnlich handhaben wie bei e-mail-attachments, wo man im Dateidialog gleich mehrere Dateien mit CTRL/shift auswählen kann.

Bloß scheint das Opera noch nicht zu unterstützen :-(

Kommentar von René

Oder wie bei mir: ich habe mir drei Zeilen für Bilder/Dateien je Beitrag gegönnt — und im Zweifelsfall muß ich halt per (s)FTP drauf, wenn ich mehr brauch.

email wird in der Version 9.6.3 schon unterstützt. Es prüft nach, ob die Eingabe der Syntax übereinstimmt und macht ein entsprechendes Symbl vor die Zeile.

Vielleicht ein Gedanke einer sinnvollen Erweiterung: ein neues Attribut (z.B. valid), dem ich einen regulären Ausdruck mit auf den Weg geben kann — und dieser wird dann im Browser geprüft.

bytheway: du kannst dich auch gerne mal per E-Mail melden.

Kommentar von wrtlprnft

Vielleicht ein Gedanke einer sinnvollen Erweiterung: ein neues Attribut (z.B. valid), dem ich einen regulären Ausdruck mit auf den Weg geben kann — und dieser wird dann im Browser geprüft.

In etwa so wie pattern?

Das Icon hab ich schon gesehen, und du hast Recht, die Validität von den Mails wird geprüft (wobei das nicht so trivial ist, »hi there«@example.com wäre in der Theorie, und in dem RFC dazu steht noch viel mehr), daran hab ich gar nicht gedacht. Aber ich würd mir so was ähnliches vorstellen wie im »An«-Feld von Operas Mailclient.

Zu dem Mail-Angebot: Das werd ich annehmen, wenn die Diskussion noch lange weitergeht und ich zu faul werd, dauernd hier nach einer Antwort zu schauen :-)

Ich habe keinen blassen Schimmer, was (jedenfalls die Vorschaufunktion) aus meinen Anführungszeichen macht, aber die Backslashes gehören da nicht hin (falls sie im endgültigen Post erscheinen)

Kommentar von René

Zu den Pattern: Ja, das ist es (Ich schaue mir später an, wie mächtig das ist).

Was das E-Mail-Formular angeht: in Opera 9.1 war email noch nicht belastet. Ich gehe davon aus, daß bei den richtigen Umsetzungen auch das E-Mail-Format korrekt implementiert ist. Wenn jetzt noch Schwachstellen gibt, ist das nicht dramatisch (Wenn bei datetime am Tag X nach 8 Uhr gefordert ist, bekomme ich im Moment auch am Tag 7 Uhr durch.)

Anführungszeichen: Ja, im Moment ein Relikt. Entdecktes Sicherheitsloch übervorsichtig gelöst. Da die ganze Seite demnächst rundumerneuert wird, will ich mich darum nicht mehr kümmern.

(Alternativ zum regelmäßigen Vorbeischauen wäre die Kommentar-RSS dieses Artikels zu empfehlen.)

Kommentar verfassen

Freiwillige Angabe
Freiwillige Angabe
Der Text kann mit Textile formatiert werden, z.B. *fett* _kursiv_ "link":url. Wie das geht?
Wieviel ist 40 plus 2?

Bisherige Trackbacks (0)

Es wurde noch kein Trackback empfangen!