Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Tipphilfen

Wir haben noch nicht alle älteren Artikel nachbearbeitet. Das bezieht sich in der Regel nur auf die Codebeispiele, die noch nicht optimal dargestellt werden.

Tipphilfen

Eingabefelder werden mit HTML5 den Anforderungen moderner Webseiten angepasst. Mit ihnen wird es möglich sein, zu überprüfen, ob Benutzer Daten, URLs oder E-Mail-Adressen richtig eingetippt haben. Stefanie Rückert führt die neuen input-Typen mit Opera vor; dem einzigen Browser, der bereits heute schon die meisten Typen unterstützt.

In diesem Teil unserer HTML5-Reihe stellen wir die neuen input-Typen gemäß der der aktuellen HTML5-Spezifikation vor. Alle Typen funktionieren zur Zeit nur im neuesten Opera-Browser. Für alle anderen Browser gibt es eine automatische Fallback-Lösung; das Feld wird dabei wie ein bekanntes, einfaches Textfeld behandelt. Durch diese Lösung ist es möglich, die neuen input-Typen schon jetzt zu integrieren.

Die folgenden Codebeispiele gibt es gesammelt als zip-Datei.

Übersicht der neuen <input>-Typen

Das input-Element ist ein Feld, in das der Nutzer einer Internetseite Daten eintragen kann. Das type-Attribut kontrolliert die Art der Dateneingabe und bedingt auch weitere mit diesem Typen verbundene Attribute. Die folgende Tabelle zeigt die neuen input-Typen gemäß des Working Draft der WHATWG Spezifikation.

Viele der neuen input-Typen funktionieren bisher nur im Opera Browser Version 10: url, email, datetime, date, month, week, time, datetime-local, number und range. Die input-Typen search und color werden derzeit von keinem Browser unterstützt.

Input-Typ Ausdruck Datentyp Eingabetyp
search Search Text ohne Zeilenumbruch Suchfeld
url URL Eine absolute URI Textfeld
email E-mail E-Mail-Adresse oder eine Liste von E-Mail-Adressen Textfeld
datetime Date and Time Ein Datum und eine Zeitangabe (Jahr, Monat, Tag, Stunde, Minute, Sekunde, Bruchteil einer Sekunde) bei gesetzter UTC-Zeitzone Datum- und Uhrzeit-Eingabe
date Date Datum, bestehend aus Jahres-, Monats- und Tagesangabe ohne Zeitzone Eine Datumseingabe
month Month Datum, bestehend aus Jahres- und Monatsangabe ohne Zeitzone Monatswert-Eingabe
week Week Ein Datum bestehend aus einer Woche-/Jahr-Eingabe – ohne Zeitzone Wochenwert-Eingabe
time Time Zeitangabe (Stunde, Minute, Sekunde, Bruchteil einer Sekunde) ohne Zeitzone Zeitwert-Eingabe
datetime-local Local Date and Time Datum und Zeiteingabe (Jahr, Monat, Tag, Stunde, Minute, Sekunde, Bruchteil einer Sekunde) ohne Zeitzone Datum- und Zeitwert-Eingabe
number Number Eine Zahl Textfeld oder ein Art Drehscheibe
range Range Eine Zahl, wobei die exakte Zahl nicht wichtig ist Ein Schieberegler oder ähnliches
color Color Eine sRGB Farbe mit 8-bit roten, grünen und blauen Komponenten Eine Farbsteuerung

Übersicht der neuen Attribute

Mit der Entwicklung von HTML5 wurden auch die Attribute aktuellen Anforderungen angepasst und neue Attribute geschaffen: autocomplete, autofocus, form, inputmode, list, max, min, pattern, replace, required, step und template.

Eine vollständige Liste aller Attribute wird bereitgestellt unter w3schools.com.

Attribut Wertebereich Beschreibung
autocomplete on|off Dient der Autovervollständigung eines input-Feldes.
autofocus boolesche Angabe (true|false) Definiert beim Laden der Internetseite das input-Feld als Ausgangspunkt.

Hinweis: Kann nicht mit type=hidden benutzt werden
form boolesche Angabe (true|false) Legt ein oder mehrere Formulare fest, zu denen das input-Feld gehört.
inputmode inputmode Legt die Art der Eingabe fest.
list ID einer Werteliste Verweist auf ein datalist-Element. Wenn dieses vorhanden ist, kann eine DropDown-Liste zur Datenweitergabe für das input-Feld genutzt werden.
max Zahlenwert Legt den Höchstwert des input-Feldes fest.
min Zahlenwert Legt den Mindestwert des input-Feldes fest.
pattern Definiert ein Muster von Zahlen oder Buchstaben, welches im input-Feld eingehalten werden soll.
replace text Legt fest, was mit dem input-Feld passieren soll, wenn das Formular abgeschickt wurde.
required boolesche Angabe (true|false) Legt fest, ob der Inhalt des input-Feldes ausgefüllt sein muss oder nicht, wenn das Formular abgeschickt wird.

Hinweis: Kann nicht mit type:hidden, image, button, submit, reset benutzt werden
step Zahlenwert Legt den Zählintervall fest.
template template (URL/id) Legt ein oder mehrere Templates fest. Das bedeutet, dass dieses Attribut eine Verbindung zu einem anderen Dokument oder einem anderen Teil des Dokumentes herstellt, welches von einem Element angesprochen werden sollte.

Zwei dieser Attribute sind allen neuen input-Typen zugeordnet: autocomplete und list.

Ersteres, von Opera auch die »Google-Suggest-Funktion« genannt, bietet die Möglichkeit der Autovervollständigung eines input-Feldes. Es ist per default aktiviert und lässt sich durch den Wert off deaktivieren. Das ist besonders beim input type="search" interessant, da so im deaktivierten Zustand die Google-Suggest-Funktion umgangen werden kann. Das Attribut hilft im aktivierten Zustand aber auch bei der Vervollständigung der URL oder der E-Mail-Adresse.

Das list-Attribut steht im Zusammenhang mit einem DropDown-Menü, wie hier im Codebeispiel zu sehen und kann ebenso auf alle anderen input-Typen angewandt werden. So entstehen zum Beispiel Listen für Suchanfragen, URL-Listen, E-Mail-Listen oder auch diverse Listen für Zeitangaben.

<input list="input_types" name="input_types">
<datalist id="input_types">
  <option value="search"></option>
  <option value="url"></option>
  <option value="email"></option>
</datalist>

Der input-Typ search

Codebeispiel

<input type="search">

Attribute

autocomplete, list, maxlength, pattern, placeholder, readonly, required, size, selectedOption, select(), selectionStart, selectionEnd, setSelectionRange(), input event, change event

Anwendungsbeispiele

Da der Typ search noch in keinem Browser funktioniert, ist es noch nicht möglich Anwendungsbeispiele zu zeigen.

Sinn dieses Elements ist es jedoch, ein Suchfeld in einem Internetauftritt zu identifizieren und es so von einem normalen Textfeld zu unterscheiden. Vom Verhalten her gleicht der Typ search dem Typ text.

So könnte beispielsweise das Suchfeld mit dem Attribut list um eine Liste von häufigen Suchbegriffen erweitert oder durch das Attribut pattern einem Muster unterworfen werden, dem die Suchanfragen genügen sollten.

Der input-Typ url

Codebeispiel

<input type="url">

Screenshot

Screenshot vom neuen Input Typ URL

Attribute

autocomplete, list, maxlength, pattern, placeholder, readonly, required, size, selectedOption, select(), selectionStart, selectionEnd, setSelectionRange(), input event, change event

Anwendungsbeispiele

Wird dem Typ url das required-Attribut hinzugefügt, überprüft der Browser automatisch die Semantik der eingegeben Internetadresse. Die Standardeinstellung erfordert ein http:// vor der eigentlichen Adresse. Jedes andere Format wird als Fehler ausgegeben.

Fehlermeldung eines Pflichtfelds

Ebenso kann das Element mit dem list-Attribut durch eine Liste von vorgegeben Internetadressen erweitert werden. Diese werden angezeigt, sobald der User in das Feld hineinklickt.

Erweiterung des URL Felds durch eine Liste

Der input-Typ email

Codebeispiel

<input type="email">

Screenshot

Screenshot vom neuen Input Typ email

Attribute

autocomplete, list, maxlength, multiple, pattern, placeholder, readonly, required, size, selectedOption, select(), selectionStart, selectionEnd, setSelectionRange(), input event, change event

Anwendungsbeispiele

Durch Hinzufügen des Attibuts required wird das E-Mail-Feld zum Pflichtfeld und beim Abschicken des Formulars abgefragt. Ist es nicht ausgefüllt, erscheint eine Fehlermeldung:

Fehlermeldung eines Pflichtfelds

Eine große Arbeitserleichterung ist meiner Meinung nach das Attribut pattern. Hiermit kann dem input-Element zusätzlich ein Muster zur Verfügung gestellt werden, welches abgefragt wird und so die Semantik der E-Mail-Adresse beeinflusst.

Hier das Codebeispiel inklusive des Screenshots mit der Fehlermeldung, die ausgelöst wird, wenn die Logik des Musters nicht eingehalten wird.

<input type="email" required="required"
  pattern="([\w]+)(([-\.][\w]+)?)
     *@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)
     |(([\w-]+\.)+))([a-zA-Z]{2,4}
     |[0-9]{1,3})(\]?)"
  name="email">

Fehlermeldung bei Missachtung des vorgegebenen Patterns in einem E-Mail-Feld

J. David Eisenberg nutzt das pattern-Attribut in dem Artikel »Get ready for HTML5« von A List Apart auch als Muster für ein Postleitzahlenfeld. Hierfür fügt er einfach einem normalen Textfeld das Attribut pattern hinzu und erweitert dieses noch durch ein Attribut title, das einen Hinweis auf die korrekte Schreibweise enthält. Das Hinzufügen des Attributs title ist allerdings nur bei einem normalen Textfeld möglich.

<p>Enter a US or Canadian Postal Code:
<input type="text" name="postCode"
required="required"
pattern="([0-9]{5}(-[0-9]{4})?)
  |([0-9][A-Z][0-9]\s+[A-Z][0-9][A-Z])"
title="US: 99999-1234; Canadian: 0A1 B2C;" />
</p> 

Fehlermeldung bei Missachtung des vorgegebenen Patterns in einem Textfeld

Das Kalender-Widget

Eine Kalenderfunktion auf der Internetseite ist eine sehr praktische Sache. Gleich fünf der neuen input-Typen warten mit diesem Feature auf. Schade ist nur, dass es sämtlichen Versuchen widersteht, sich grafisch anpassen zu lassen. Einzig elementare Dinge, wie die Schriftgröße und Farbe lassen sich ändern. Die Farbe allerdings auch nur im input-Feld direkt und nicht im Kalender-Widget selbst. Dort sind nur die Schaltflächen »Heute« und »Keins« betroffen.

Ob Designer sich mit diesen eingeschränkten Gestaltungsmöglichkeiten zufrieden geben werden ist fraglich. Vielleicht wird in der zukünftigen Entwicklung der input-Elemente noch die Möglichkeit berücksichtigt, die einzelnen Felder individuell gestalten zu können, aktuell ist es jedoch nicht so. Aus dem gestalterischen Blickwinkel stellt sich die Frage, ob die Typen datetime, datetime-local, date, month und week dann überhaupt angenommen werden.

Da die Entwicklung von HTML5 allerdings noch nicht abgeschlossen ist, besteht die Möglichkeit, dass die gestalterische Anpassung des Kalenders noch nachträglich hinzugefügt wird.

Der input-Typ datetime

Codebeispiel

<input type="datetime">

Screenshot

Screenshot vom neuen Input-Typ datetime
Screenshot vom neuen Input-Typ datetime

Attribute

autocomplete, list, max, min, readonly, required, step, valueAsDate, valueAsNumber, selectedOption, stepDown, stepUp, input event, change event

Anwendungsbeispiele

Der Typ datetime verfügt als einziges der neuen Zeit/Datum-Elemente über die Angabe einer Zeitzone. Diese bezieht das input-Element aus der Systemzeit. Die Möglichkeit, die aktuelle Zeit mitzugeben, funktioniert noch nicht.

Der input-Typ datetime-local

Codebeispiel

<input type="datetime-local">

Screenshot

Screenshot vom neuen Input-Typ datetime-local
Screenshot vom neuen Input-Typ datetime-local

Attribute

autocomplete, list, max, min, readonly, required, step, valueAsNumber, selectedOption, stepDown, stepUp, input event, change event

Anwendungsbeispiele

Der Typ datetime-local funktioniert analog zum Typ datetime, gibt aber nur die lokale Zeit aus – ohne die Nennung der Zeitzone. Es ist möglich, dass datetime-local im Laufe der Entwicklung von HTML5 ein Teil von datetime wird und die Zeitzone als Attribut hinzugefügt werden kann, da sich die beiden Typen nur in der genannten Eigenschaft unterscheiden.

Die input-Typen date, month und week

Codebeispiele

<input type="date">
<input type="month">
<input type="week">

Screenshots

Screenshot vom neuen Input-Typ date
Screenshot vom neuen Input-Typ date, month und week ohne Kalenderwidget

Screenshot vom neuen Input-Typ date mit Kalenderwidget
Screenshot vom neuen Input-Typ date mit Kalenderwidget

Screenshot vom neuen Input-Typ month
Screenshot vom neuen Input-Typ month mit Kalenderwidget

Screenshot vom neuen Input-Typ week
Screenshot vom neuen Input-Typ week mit Kalenderwidget

Attribute

autocomplete, list, max, min, readonly, required, step, valueAsDate, valueAsNumber, selectedOption, stepDown, stepUp, input event, change event

Anwendungsbeispiele

Der Typ date funktioniert analog zum Typ datetime, gibt aber anstelle eines Datums inklusive der Uhrzeit nur das Datum (Jahr-Monat-Tag) aus. Der Typ month funktioniert analog zum Typ date, ist aber auf den Monat und das Jahr beschränkt. Der Typ week schließlich funktioniert analog zum Typ date, gibt aber anstelle eines Datums die Kalenderwoche aus.

Der input-Typ time

Codebeispiel

<input type="time">

Screenshots

Screenshot vom neuen Input-Typ time
Screenshot vom neuen Input-Typ time mit step=0.01

Attribute

autocomplete, list, max, min, readonly, required, step, valueAsDate, valueAsNumber, selectedOption, stepDown, stepUp, input event, change event

Anwendungsbeispiele

Der Typ time zeigt eine Uhrzeit an, die standardmäßig in Sekundenschritten hoch- oder runtergezählt wird. Mit dem Attribut step kann die Uhrzeit bis auf Millisekunden genau eingestellt werden und bietet so genügend Freiraum zur Modifizierung.

Der input-Typ number

Codebeispiel

<input type="number">

Screenshot

Screenshot vom neuen Input-Typ number

Attribute

autocomplete, list, max, min, readonly, required, step, valueAsNumber, selectedOption, stepDown, stepUp, input event, change event

Anwendungsbeispiele

Der Typ number eignet sich für die Eingabe verschiedener Zahlenwerte. Durch das Attribut step kann das Zählintervall beeinflusst werden und durch die Attribute min und max kann der Bereich abgesteckt werden, in dem sich die ausgewählte Zahl befinden soll.

Screenshot vom neuen Input-Typ number mit step='0.001'
Der Screenshot zeigt das input-Feld number, wenn das Attribut step den Wert 0.001 hat.
Standardmäßig ist dem Attribut step der Wert 1 zugeordnet, sowie dem Attribut min 0 und dem Attribut max 100.

Der input-Typ range

Codebeispiel

<input type="range" min="2000" max="2050" value="2009" onInput="year.value=value">
<output name="year"></output>

Screenshot

Screenshot vom neuen Input-Typ range

Attribute

autocomplete, list, max, min, step, valueAsNumber, selectedOption, stepDown, stepUp, input event, change event

Anwendungsbeispiele

Der Typ range funktioniert analog zum Typ number, nur dass er zum einen weniger Attribute besitzt und zum anderen, wie im Screenshot zu sehen, eine andere grafische Ausgabe. Zudem kommt der Typ mit dem neuen output-Element daher, das den durch den Schieberegler erzeugten Wert ausgibt.

Da dieser Typ auch in den Webforms2 von Weston Ruter nicht aufgegriffen wird (siehe unten) und auch das Element output dort keine Verwendung findet, kann man die Schiebereglerfunktion im Alltag noch nicht verwenden. Für die Zukunft bietet dieser Regler allerdings eine interessante grafische Variante zur Darstellung von Zahlenwerten. Da auch dieses Element noch nicht grafisch anpassbar ist, stellt sich allerdings auch hier die Frage, ob sich die Verwendung dieses Reglers durchsetzen wird.

Der input-Typ color

Codebeispiel

<input type="color">

Attribute

autocomplete, list, selectedOption, input event, change event

Anwendungsbeispiele

Da der Typ color noch in keinem Browser funktioniert, ist es noch nicht möglich, Anwendungsbeispiele zu zeigen. Gedacht ist dieser Typ als Farbauswahlfeld auf 8-bit-Basis. Das bedeutet, dass voreingestellte Hexadezimalwerte ausgewählt werden können, die einem bestimmten Farbwert entsprechen. Es ist immer automatisch ein Farbwert ausgewählt, denn dieses Feld darf per Definition niemals leer sein. Wird ein invalider Wert eingegeben, wird der Inhalt des Feldes automatisch auf #000000 gesetzt.

Und die anderen Browser?

Da die neuen input-Typen bisher nur im Opera 10 funktionieren, stellt sich natürlich die berechtigte Frage, ob diese schon mit dem ein oder anderen Workaround in anderen Browsern genutzt werden können.

Weston Ruter hat über Google Code die Webforms2 zur Verfügung gestellt, welche es ermöglichen, die neuen Typen auch schon in folgenden Browsern zu nutzen:

  • Mozilla Firefox 1.0.8
  • Mozilla Firefox 1.5.0.9
  • Mozilla Firefox 2
  • Internet Explorer 6
  • Internet Explorer 7
  • Safari 2.0.4
  • Safari 3 (Windows)

Die oben genannten Browser wurden laut Weston Ruter getestet; ich kann hinzufügen, dass der Firefox 3.5 mit den Webforms2 kompatibel ist.

Obwohl diese Lösung natürlich unkompliziert und sehr vorteilhaft ist, ist sie dennoch bloß der Krückstock unter den Gehhilfen. Solange einem nichts besseres bekannt ist, ist es auch in Ordnung; hat der User aber den Vergleich im Opera 10 gesehen, ist der Unterschied offensichtlich. Es soll natürlich auch nur eine Übergangslösung sein, bis alle Browser die HTML5 Standards integriert haben. Dennoch gibt es genügend Kritikpunkte.

Zunächst einmal übernehmen die Webforms2 nicht die grafischen Unterscheidungen der input-Felder. Das bedeutet, dass jeder Typ wie ein normales Textfeld aussieht. Die einzelnen Widgets, zum Beispiel beim Typ datetime wurden auch noch nicht umgesetzt, was wiederum bedeutet, dass diese Felder wie ein normales Textfeld reagieren. Es gibt einen Workaround für den Typ date, der aber durch eine CSS-Datei erst gestylt werden muss, das heißt, dass das Webforms2-Standardmodell dem HTML5-Standardmodell nicht gerade ähnlich sieht. Hier ist noch viel Eigeninitiative gefragt. Ebenso wenig funktionieren die Typen time, number und range. Hierfür gibt es auch noch keine Javascript-Workarounds.

Die Fehlermeldungen sind standardmäßig in englischer Sprache. Sie können aber im Javascript in die gewünschte Sprache umgeschrieben werden. Javascript ist natürlich der nächste Punkt: Wer es ausgeschaltet hat, wird automatisch ausgeschlossen. Damit fallen die Webforms2 in einen experimentellen und nicht alltagstauglichen Bereich, der gegen eine offizielle Benutzung spricht.

Die Webforms2 unterstützen auch noch nicht alle neuen Attribute. Bisher integriert sind die Attribute pattern, required, min und max, step und das autofocus. Da das list-Attribut noch nicht unterstützt wird, funktioniert mein Beispiel dazu auch nur im Opera 10.

Das Einbinden der Webforms2 behindert die standardmäßige Interpretation des Opera 10 nicht, von daher kann dies bedenkenlos getan werden. Will der Webworker jedoch auf Nummer Sicher gehen und keinen Nutzer ausschließen, sollte er mit der Verwendung der neuen input-Typen besser bis zur Integration in allen Browser warten. Denn trotz aller schönen Neuerungen ist der Opera nur ein Nischenprodukt.

Diese Einschränkungen machen die neuen input-Typen und die Attribute zu Versuchsobjekten und verhindern eine weite Verbreitung und öffentliche Nutzung.

Fazit:

Die neuen input-Typen sind vielversprechend und kommen mit vielen neuen Features daher, die jeden Internetauftritt aufwerten können. Der Code ist schlank und durch die neuen Attribute können viele Javascript-Lösungen, etwa zur Pflichtfeldabfrage oder zur Syntax einer E-Mail-Adresse, eingespart werden.

Dennoch werden die neuen Typen wohl erst in ferner Zukunft vermehrt genutzt werden, denn der bisherige Workaround mit den Webforms2 ist alles andere als befriedigend. Hier bleibt einem nichts anderes übrig, als darauf zu warten, dass die input-Typen bald in allen gängigen Browsern integriert werden. Oder aber der ambitionierte Webworker schreibt sich auf Basis der Webforms2 einfach seine eigenen Workarounds.

Das kann jedoch nicht die Lösung sein und so wird es nun wohl zunächst nur zu einer Arbeitserleichterung durch die Attribute required und pattern kommen – und das auch nur durch ein Javascript-Workaround.

Ich persönlich bin gespannt, was die Zukunft in Sachen HTML5 noch bringen wird und bin mit meiner Spannung auch nicht allein. Sowohl in der neuen Weave als auch in dem Artikel von J. David Eisenberg auf A List Apart und auch noch in vielen anderen Diskussionen im World Wide Web, kann man lesen, dass Spannung in der Luft liegt.

»Although some developers have reservations about the direction in which HTML5 is taking the web (and although I share these reservations), HTML5 has enough new and interesting features to be well worth exploring. So, start looking at other people’s markup, experiment on your own, and go wild with the new form validation and canvas features.«

Und mit diesen Worten von J. David Eisenberg möchte ich auch schließen. Experimentiert selbst ein wenig mit den neuen input-Typen und bildet euch euer eigenes Urteil – ihr werdet es nicht bereuen.

Kommentare

Sebastian Kippe
am 01.10.2009 - 17:50

Da der Typ search noch in keinem Browser funktioniert, ist es noch nicht möglich Anwendungsbeispiele zu zeigen.

Das stimmt nicht ganz. In Safari funktioniert das schon seit langem und gibt ein hübsches Apple-Suchfeld aus. Die Attribute placeholder und results sorgen darüberhinaus für das echte Suchfeld-Feeling.

Außerdem wird der Input-Typ in Browsern, die ihn nicht unterstützen, zu einem normalen Textfeld degradiert, sodass der Benutzung auch keine Kompatibilitätsprobleme im Wege stehen.

Permanenter Link

Gunther
am 03.10.2009 - 18:32

Hallo!

Sehr schöne und übersichtliche Vorstellung der neuen Input-Typen - vielen Dank an die Autorin.

Zunächst noch einige inhaltliche Bemerkungen zu dem Artikel:
Auch der Safari (Win 4.0.2) bringt wohl auch schon eine gewisse/ teilweise native Unterstützung der Input-Typen mit. So wird bspw. beim Typ Range auch ein Slider dargestellt, allerdings wird der Wert (in Output) nicht angezeigt.

Wie mir scheint ist die Liste auch nicht ganz vollständig. So fehlen u.a. die Typen 'Telephone' und 'File Upload'.

Wer hier auch öfter die Kommentare liest weiß, dass ich kein Freund des derzeitigen HTML 5 Entwurfes bin. ;-)

Daran ändern auch die vermeintlich hilfreichen & praktischen neuen Input-Typen nichts!

Denn damit verabschieden wir uns dann endgültig von HTML als reine Auszeichnungssprache, indem dann nämlich auch eine gewisse Form von 'Logik' mit integriert wird. Diese hat aber imho in einer beschreibenden Textauszeichnungssprache nichts verloren.
Schlimmer noch: Wir geben die Kontrolle/ Steuerung dieser Logik auch noch aus der Hand! Nicht der Webautor kann diese steuern, sondern der jeweilige Browserhersteller. Höchst unterschiedliche Verhaltensweisen werden die Folge sein, wie man jetzt schon alleine am Vergleich von Opera 10 und Safari 4 sehen kann. So verweigert Opera bspw. das Absenden des Formulars, wenn ein Eingabefeld eine unzulässige Eingabe enthält, während der Safari diese lediglich rot gestrichelt unterlegt.

Wenn man also schon hingeht und solche 'Kontroll-Mechanismen' in die Browser implementiert (was ich vom Grundsatz her für falsch halte), dann doch bitte so, dass sie lediglich als 'Fallback' fungieren, falls der Webautor nicht per JS seine eigenen Mechanismen mitliefert, bzw. der User JS deaktiviert hat. Wobei mir in letzterem Fall eine serverseitige Überprüfung immer noch sinnvoller erschiene.

Kurz (und absichtlich 'bissig') gesagt, kommt mir dabei der Gedanke in den Sinn, ob man es anstatt HTML 5 nicht besser 'Hicksons DHTML Spielerei' nennen sollte!?

Und auch unter dem Blickwinkel der Accessibility bin ich mir (noch) nicht sicher, wie tauglich das neue Konzept ist.
So nimmt Opera 10 bspw. in keinem der 'date...' Felder eine Tastatureingabe an. Stattdessen öffnet sich grundsätzlich das Kalender-Widget, welches im übrigen auch nicht mitscrollt und bei dessen Links sich der Mauszeiger nicht zum Pointer verändert. Immerhin passt es sich der jeweiligen Zoomstufe an.

Alles in allem bin ich der Meinung, dass man die Dinge da belassen sollte, wo sie vom System her auch hingehören. Vor allem sollte die volle Kontrolle über seine Webanwendung beim jeweiligen Autor liegen und nicht abhängig sein von dem vom jeweiligen User verwendeten Browser.

Gruß Gunther

Permanenter Link

Die Kommentare sind geschlossen.