Problem mit width: 25% bei drittem div > ul > li

[Christian Kruse]

Hallo Gunnar,

Zur Datumseingabe bietet HTML einen speziellen Typen und Browser spezielle UI-Elemente an. Nutze sie!

Unsupported für Safari, Firefox und Opera Mini. Support für IE erst ab Edge (und da auch nur teilweise).

Das zu empfehlen ist sehr zweifelhaft; man benötigt dann zwingend einen Polyfill.

Nein. Eben nicht. Der Fallback ist bereits da: Browser, die type="date" nicht verstehen, ignorieren das type-Attribut, zeigen also ein ganz normales Eingabefeld an.

Beleuchten wir das mal aus den Blickwinkeln technische Machbarkeit, User-Experience und Kunden-Akzeptanz.

Aus technischer Sicht muss man um das umzusetzen einen Date-Parser schreiben, der die verschiedenen Formate und deren Abwandlungen zweifelsfrei erkennt und das Datum richtig parsed. Du musst also zuerst mal unterscheiden können zwischen den Reihenfolgen der Angaben:

• DMY
• YMD
• MDY

Die Schreibweisen verteilen sich auf die Welt, teilweise wird im gleichen Land beides verwendet. Das ist völlig unrealistisch, das ist eindeutig nicht erkennbar. Nehmen wir z.B. Brasilien und die USA: Brasilien verwendet überwiegend dd/mm/yyyy. Die USA verwendet überwiegend mm/dd/yy und mm/dd/yyyy. Hier ist also schon ein Konflikt, der nicht eindeutig detektierbar ist. Aber wir brauchen gar nicht über Landesgrenzen gehen. Schauen wir uns mal Canada an. Dort gibt es (neben anderen Schreibweisen) DD/MM/YYYY, MM/DD/YYYY, YY/MM/DD - zack, wieder ein paar Konflikte, die nicht detektierbar sind.

Es gibt noch mehr Probleme, wenn wir uns die Schreibweisen in Europa betrachten. Das zu recherchieren verbleibt dem geneigten Leser.

Betrachten wir das aus Usability-Sicht: statt eines Date-Pickers haben wir nun also einfach nur ein Textfeld, in die ein Datum eingegeben werden soll. Die User-Reaktion kann sich jetzt auf zweierlei Art äussern: er trägt Gedankenlos das Datum in seinem gewohnten Format ein. Bei einer Zweideutigkeit aufgrund des Formats muss dem User entweder das Datum erneut vorgesetzt werden mit der Information, dass das Datum so zweideutig ist oder es ist schlicht das falsche (sprich das nicht vom User gemeinte) Datum. Geile UX, muss man schon sagen...

Die zweite mögliche Reaktion ist Verwirrung. „In welchem Format soll ich das eingeben? Was erwartet der Software-Entwickler?“ Auch nicht sonderlich sinnvoll.

Eine Möglichkeit dem entgegen zu wirken wäre es, einen Hinweis-Text einzublenden, welches Format erwartet wird. Das müsste man via JS einblenden wenn das type="date"-Atttribut nicht unterstützt wird. Schön ist anders, der Komfort geht vollständig flöten.

Alles in allem: technisch nicht sinnvoll umsetzbar, es sei denn man stellt den User vor eine ziemlich hohe Hürde.

Aus der Sicht des Kunden kann ich aus Erfahrung sagen: ich habe noch keinen Kunden getroffen, der ein einfaches Text-Eingabefeld für ein Datum akzeptiert hat. Ich musste das immer rechtfertigen und habe den Kunden nur mit einem Polyfill und dem Hinweis, dass das Textfeld nur noch bei Nicht-JS-Usern auftaucht zufriedenstellen können.

Mein Fazit bleibt: die Verwendung von Date-Time-Input-Feldern ist problematisch und bleibt mit gravierenden Nachteilen verbunden.

LG,
CK