Mit HTML-Attributen können Sie eine beeindruckende Menge an Formularvalidierungen durchführen. Mit CSS-Selektoren können Sie die Benutzererfahrung ziemlich sauber und klar gestalten. Aber es erfordert etwas CSS-Trickser, um alles richtig hinzubekommen!
(Sie können) das Label wie einen Platzhalter aussehen lassen
Zuerst: Verwenden Sie immer echte <label for="correct_input"></label>-Elemente. Allein das ist schon ein UX-Gesichtspunkt, den zu viele Formulare vernachlässigen. Platzhalter sind Vorschläge für gültige Eingaben, wie z. B. "Tulsa" in ein Feld "Stadt" einzugeben.
Ich würde sagen, wenn das Formular kurz ist und ein offensichtliches Muster hat (wie An- oder Abmeldung), könnten Sie das visuelle Platzhaltermuster verwenden, aber stattdessen echte Labels.
Nehmen wir ein Formular wie…
<form action="#0" method="post">
<div>
<input type="text" id="first_name" name="first_name">
<label for="first_name">First Name</label>
</div>
<!-- ... --->
</form>
Sie verwenden die <div>
form {
max-width: 450px;
// positioning context
> div {
position: relative;
// Looks like placeholder
> label {
opacity: 0.3;
position: absolute;
top: 22px;
left: 20px;
}
}
}
Sie müssen keine kniffligen Cursor-Sachen machen, weil es bereits semantisch verdrahtet ist. Wenn sie auf den vom Label eingenommenen Bereich klicken, wird die Eingabe aktiviert. Wenn sie auf die Eingabe klicken, wird die Eingabe aktiviert. Beides richtig.
Der Trick ist, die Eingabe *zuerst* zu setzen (semantisch in Ordnung), damit Sie das Label beim Fokus ausblenden können
form {
/* ... */
> div {
> input[type="text"],
> input[type="email"],
> input[type="password"] {
&:focus {
& + label {
opacity: 0;
}
}
}
}
}

Bestimmte Eingaben als erforderlich kennzeichnen
Die vielleicht einfachste Validierung eines Formulars, die Sie durchführen können, ist die Verwendung des required-Attributs, um ein Feld als erforderlich zu markieren. Kein schnellerer Weg, einen Fehler zu erkennen, als den Browser es tun zu lassen, wenn er kann!
<input
required
type="text"
id="first_name"
name="first_name">

Gültige Eingabewerte positiv anzeigen
Benutzer darüber informieren, dass ein Feld korrekt eingegeben wurde. Der Browser kann uns diese Information über den CSS-Selektor :valid zur Verfügung stellen.
form {
> input[type="text"],
> input[type="email"],
> input[type="password"] {
// show success!
&:valid {
background: url(images/check.svg);
background-size: 20px;
background-repeat: no-repeat;
background-position: 20px 20px;
// continue to hide the label
& + label {
opacity: 0;
}
}
}
}
}

:valid stellt in diesem Fall sicher, dass die erforderliche Bedingung erfüllt ist, aber dieser Selektor ist auch nützlich für die Validierung des Eingabetyps.
Hinweise zur Typvalidierung anzeigen
Sie können auch verlangen, dass der Wert einer Eingabe einem bestimmten Typ entspricht, z. B. email oder number. Hier sind Beispiele für alle.
<input id="email" name="email" required="" type="email">
Diese Eingabe ist sowohl erforderlich als auch muss dem gültigen E-Mail-Adressformat entsprechen. Machen wir das für die UX
- Informieren Sie den Benutzer bei Fokus auf das Feld über die Anforderungen
- Erinnern Sie ihn daran, dass das Feld andernfalls keinen gültigen Wert hat
Aber auch… zeigen Sie keine Hinweise an, wenn die Eingabe leer ist. Das heißt, nehmen Sie keinen ungültigen Zustand an. Das ist einfach nur ärgerlich und unnötig negativ. Um das zu tun, müssen wir wissen, ob die Eingabe leer ist oder nicht.
Untertrick! Testen, ob eine Eingabe einen Wert hat oder nicht
Wir möchten Dinge mit :valid und :invalid tun, aber wir möchten nicht zu voreilig mit :invalid sein und es verwenden, bevor die Eingabe einen Wert hat.
Gibt es einen CSS-Selektor, um zu testen, ob eine Eingabe leer ist? Nicht wirklich! Man sollte denken, :empty wäre es, aber das ist es nicht. Das gilt für Dinge wie </code>
</code>… Container-Elemente, die nichts darin enthalten. Eingaben sind bereits Elemente ohne Inhalt.
Der Trick besteht darin, sicherzustellen, dass die Eingabe einen Platzhalterwert hat, und dann
input:not(:placeholder-shown) {
}
Wir verwenden den Platzhalter in unserer Demo nicht wirklich, aber ein Leerzeichen funktioniert
<input type="text" placeholder=" ">
:placeholder-shown ist hier super nützlich für uns! Es ist im Grunde der geheime Selektor, um zu testen, ob eine Eingabe derzeit einen Wert hat oder nicht.
Es gibt keine IE- oder Firefox-Unterstützung dafür, was besonders schwierig zu umgehen ist. Mit neuen Funktionen wie dieser ist @supports normalerweise eine Rettung, aber…
/* This doesn't work */
@supports (input:placeholder-shown) {
input:not(:placeholder-shown) {
}
}
Sie können @supports nicht für Selektoren verwenden, nur für Eigenschaften/Werte (z. B. @supports (display: flex))
Das Testen der Platzhalterunterstützung in JavaScript ist einfach genug
var i = document.createElement('input');
if ('placeholder' in i) {
}
Aber es scheint keinen einfachen Weg zu geben, :placeholder-shown zu testen. Also… das muss vielleicht einfach auf tiefere Browserunterstützung warten, um es für große Produktionssachen zu verwenden.
Unter der Annahme wunderbarer Unterstützung würde die Logik so aussehen…
form {
> div {
> input[type="text"],
> input[type="email"],
> input[type="password"] {
// When input is...
// 1. NOT empty
// 2. NOT in focus
// 3. NOT valid
&:invalid:not(:focus):not(:placeholder-shown) {
// Show a light reminder
background: pink;
& + label {
opacity: 0;
}
}
// When that invalid input becomes in focus (and also still isn't empty)
&:invalid:focus:not(:placeholder-shown) {
// Show the more robust requirement instructions below.
& ~ .requirements {
max-height: 200px;
padding: 0 30px 20px 50px;
}
}
}
// <input> ~
// <label> ~
// <div class="requirements">
.requirements {
padding: 0 30px 0 50px;
color: #999;
max-height: 0;
transition: 0.28s;
overflow: hidden;
color: red;
font-style: italic;
}
}
}

Sie können robuste Validierungen erstellen
Es ist nicht nur required oder type="email" (und ähnliches), Sie können auch clientseitig Dinge wie die Länge (z. B. minimale Passwortlänge oder maximale Zeichen in einer Bio-Textarea) validieren und sogar vollwertige Regex verwenden.
Hier ist ein Artikel dazu. Sagen wir, Sie möchten Passwortanforderungen wie
- Mindestens 6 Zeichen
- Mindestens 1 Großbuchstabe
- Mindestens 1 Kleinbuchstabe
- Mindestens 1 Zahl
Das können Sie so tun
<input pattern="(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{6,}" type="password" id="password" name="password" required placeholder=" ">

Demo
Ich lasse die :placeholder-shown-Sachen hier drin, was das in Firefox und IE nicht gut funktionieren lässt völlig in Ordnung macht, weil es jetzt unterstützt wird, außer IE 11.
Viele großartige Tricks hier, aber ich bin mir nicht sicher, ob
opacity: 0der beste Ansatz für die Labels ist. Das verhindert, dass Sie in zuvor eingegebenen Text klicken können, wo das (unsichtbare) Label darüber liegt. Wie wäre es mitdisplay: noneoderpointer-events: none?Man könnte das Label auch vom Bildschirm nach links schieben oder das Clip()-Ding verwenden. In diesem Fall schadet es der Klickbarkeit nicht, da…
Was ich in der Vergangenheit für Labels in Eingabefeldern gemacht habe, ist, die Labels visuell auszublenden, indem ich
display: block;,height: 0;,overflow: hidden;auf den Labels verwende… und einfach das Platzhalterattribut für die visuell sichtbaren Labels verwende… Sie können den Platzhalters Text mit Pseudoselektoren gestalten…Meine Frage… ist das in Ordnung? oder ist das semantisch in Ordnung? Meine Überlegung bei diesem Ansatz war, dass Screenreader die Labels immer noch vorlesen würden… aber sie wären für sehende Benutzer visuell verborgen…
Chris, du hast Recht, aber ich meine das Klicken buchstäblich *in* den Text. Zum Beispiel mitten drin. Geben Sie einen Namen in das Feld "Vorname" ein, und versuchen Sie dann, zwischen den ersten beiden Zeichen zu klicken. Das Eingabefeld wird fokussiert, aber es platziert den Cursor am Ende des Textes. Nicht sehr benutzerfreundlich :)
Ein wichtiger Punkt beim Klicken *in* den Text!
Es scheint, als wäre dies der Weg.
(Anpassen des Selektors an die Demo.)
Ein weiterer Trick, den ich früher verwendet habe, um das Klicken auf das Label anstelle des Eingabetextes zu vermeiden, war, das Label mit z-index unter das Feld zu legen und dem Eingabefeld einen transparenten Hintergrund zu geben.
Der Feld-Wrapper kann einen Hintergrund zurückgeben.
Was ich auch gerne mache, wenn das Design es zulässt, ist, das Label während des Fokus in einen sichtbaren Bereich zu verschieben, damit ein Benutzer das Label beim Tippen immer noch sehen kann.
Oder noch besser: Machen Sie das Label jederzeit sichtbar! Besonders wenn beispielsweise Autofill verwendet wird, überprüfe ich gerne, ob alle Felder korrekt ausgefüllt sind. Diese Technik ist nett, sollte aber meiner Meinung nach nur für sehr kleine Formulare (wie eine Suchleiste oder Anmeldung) verwendet werden, wo sie die Benutzerfreundlichkeit nicht beeinträchtigt.
Und ich frage mich, ob alle Screenreader korrekt funktionieren, wenn Labels nach Eingaben platziert werden, auch wenn die for- und id-Verbindungen korrekt sind.
Dafür ist das Muster des schwebenden Labels sehr gut geeignet.
Ich wünschte, ich könnte auf eine Antwort antworten, aber na ja.
Was ich der Unterhaltung hinzufügen möchte, ist: Ich stimme @René in allem zu.
:placeholder-shownist nett, das hatte ich vorher noch nicht gehört.Das Hin- und Herwechseln zwischen gültig und ungültig, während Sie eine E-Mail-Adresse eingeben, ist ziemlich schwierig. Sie könnten so etwas tun
Was ein paar Dinge erreicht.
1. Solange jemand einigermaßen schnell tippt, wird es nicht zwischen ungültig und gültig wechseln, was natürlich zweimal passiert, während Sie eine E-Mail-Adresse eingeben
2. Es beeinträchtigt keine anderen Felder (dieses Hin und Her sollte nirgendwo anders passieren, und sofortiges Feedback ist im Allgemeinen vorzuziehen)
3. Es gibt keine Verzögerung, wenn jemand eine ungültige E-Mail *korrigiert*, was meiner Meinung nach wichtig ist
Ich mag es.
Das ist super clever! Wie eine
debounce()-Methode in CSS!Hat mir der :placeholder-shown Trick gefallen! Gibt es ein Polyfill für nicht unterstützte Browser?
Was passiert, wenn das Feld ausgewählt ist, aber nichts hineingetippt wurde? Verschiedene Browser behandeln Platzhalter unterschiedlich. Einige verstecken den Platzhalter sofort, sobald das Feld ausgewählt ist. Andere warten, bis mit dem Tippen begonnen wurde.
In Fällen, in denen er beim Fokus ausgeblendet wird, wird nicht unbedingt angezeigt, dass das Feld einen Wert hat. Es wird nur angezeigt, dass der Platzhalter nicht angezeigt wird. Und das mag ein Grenzfall sein, aber es ist durchaus möglich. Richtig?
Toller Artikel! Mein einziger Vorbehalt ist bei den Validierungsnachrichten für E-Mail-Adressen und Passwörter während der Eingabe. Ein Benutzer beginnt zu tippen und sieht eine rote Fehlermeldung, bis die Eingabe gültig ist. Ich sehe das auf immer mehr Websites und verstehe, dass es sich um eine progressive Validierung handelt, die nach einem Sendeversuch keine Überarbeitung erfordert. Meine UX, wenn ich damit konfrontiert werde, ist
„Ich versuche, ein gültiges Passwort einzugeben, hoffentlich ein gutes, das mit den Anforderungen übereinstimmt. Das erfordert Konzentration und diese Nachricht ist ablenkend.“
„Ich möchte nicht gesagt bekommen, dass ich falsch liege, bevor ich es bin.“
Ich glaube nicht, dass der Zeitpunkt falsch ist, aber ich hinterfrage die Art des Feedbacks. Ich würde es vorziehen, wenn Passwortvalidierungsregeln vor der Eingabe angezeigt würden. Ich würde die abstraktere, meiner Meinung nach weniger ablenkende Validierung für Vor- und Nachnamen bevorzugen. Ich denke, der ikonische Hinweis ist ein besseres Feedback, obwohl ich immer noch eine „X“-Ikone vermeiden würde.
Ich bin mir bewusst, dass dies eine UX-Angelegenheit und keine CSS-Angelegenheit ist, aber ich dachte, ich würde sie trotzdem anbieten. :-)
@Eric Carlisle,
Ich war schon immer ein Fan von MailChimp's Ansatz für das Passwortfeld, bei dem die Anforderungen im Voraus angezeigt werden, sie während des Tippens abgehakt werden und man eine Bestätigung erhält, sobald alle Anforderungen erfüllt sind.
https://login.mailchimp.com/signup
Firefox hat den benutzerdefinierten Pseudoselektor
-moz-ui-invalid, der genau der Detektor ist, den Sie für ungültig wünschen würden. Er zeigt den ungültigen Zustand erst nach dem Blur oder dem ersten Senden an, aber dann bei jedem einzelnen Zeichen.https://developer.mozilla.org/en/docs/Web/CSS/:-moz-ui-invalid
Ich würde auch dringend empfehlen, Webshim als Polyfill für die Formularvalidierung zu verwenden, es bietet ein JS-Backup für alles, das native HTML5-Markup wo möglich und viel mehr verwendet.
Sehr clever! Ein negativer Nebeneffekt ist, dass man die eingegebene E-Mail-Adresse nicht (einfach) mit der Maus auswählen kann.
Super!
Meiner Meinung nach ist es in vielen Fällen nicht ratsam, das Label zu verstecken, da dies die Benutzerfreundlichkeit/Barrierefreiheit beeinträchtigen kann. Nachdem ich ein solches Formular ausgefüllt habe, wird es schwierig, sich zu erinnern, welches Label zu welchem Feld gehört. Das mag bei "Vorname" oder E-Mail-Adresse offensichtlich sein, aber das ist nicht immer der Fall. Außerdem ist es schwierig, nachträglich zu überprüfen, ob man alle Felder korrekt ausgefüllt hat, da die entsprechenden Labels fehlen.
Daher mag ich Ansätze, bei denen das Label immer noch angezeigt wird, auf eine weniger aufdringliche Weise wie diese
http://codepen.io/MattDiMu/pen/bepmEK
+1
Das ist einfach so cool, danke Leute
Zunächst einmal vielen Dank für den großartigen Artikel.
Meine einzige Frage ist, wie würde man das `required`-Attribut mit Selenium oder einem ähnlichen automatisierten Testframework testen? Ich glaube nicht, dass es möglich wäre, den Text der Nachricht abzurufen oder zu überprüfen, ob die Nachricht erschienen ist, da sie meines Verständnisses nach keine separate HTML-Markup auf der Seite hat.
Die Requirements-Div hat `max-height: 0` als Anfangszustand und `max-height > 0` bei ungültiger Eingabe + Fokus.
Das ist testbar.
Was bereits testbar ist, ist das `required`-Attribut selbst: Füllen Sie alle anderen Felder aus oder entfernen Sie sie und führen Sie einen skriptgesteuerten Submit durch.
Ich muss zugeben, dass ich nicht viel Erfahrung mit Selenium habe und es wahrscheinlich bessere Wege gibt, das zu überprüfen.
Großartige Sachen! Beachten Sie, dass jede clientseitig durchgeführte Validierung deaktiviert werden kann. Validierung muss also auch im Backend vorhanden sein, es sei denn, Sie möchten das Risiko eingehen, dass falsche oder unsichere Daten über das Formular übermittelt werden.
Das ist großartig für die UX!
Ich verstehe immer noch nicht, warum wir Labels (als Platzhalter) anstelle der richtigen Platzhalter verwenden sollten, die für diesen Zweck entwickelt wurden?
Platzhalter und Labels haben unterschiedliche Zwecke.
Platzhalter sind dazu gedacht, einen Hinweis zu geben, wie ein Feld ausgefüllt werden soll. Labels sind dazu gedacht, zu beschreiben, was ausgefüllt werden soll. Außerdem bleiben Labels (sofern nicht gehackt wie in diesem Beitrag) sichtbar, wenn das Feld gefüllt ist.
z.B.
<label>EAN<input type=text required name=postal placeholder='nur Ziffern wie 013983'></label>https://www.w3.org/WAI/GL/wiki/Using_@placeholder_on_input
Danke, ich verstehe den allgemeinen Zweck von Labels, aber ich verstehe immer noch nicht, warum wir ihren Hauptzweck (Bedeutung) ändern und sie stattdessen als Platzhalter verwenden sollten?
Labels (soweit ich das verstehe) wurden nicht dafür entwickelt,
sondern wie Sie richtig sagten, sie sollten beschreiben, was in das Eingabefeld eingegeben werden soll und immer sichtbar sein.
Ästhetik.
Designer wollen Platzhalter – Programmierer (und Barrierefreiheitsleute etc.) wollen Labels.
Also machen wir als Kompromiss Labels wie Platzhalter aussehen.
Wie einige Kommentare bereits sagten, es kann gemacht werden, aber das bedeutet nicht, dass es eine gute Praxis ist.
Ich stimme Ihnen vollkommen zu, besonders diesem Teil: „es kann gemacht werden, aber das bedeutet nicht, dass es eine gute Praxis ist.“.
Aber denken Sie an Neulinge, die diesen Artikel lesen, wo Chris Coyier, der eine Autorität im Webdesign hat,
sagt: „…könnten Sie das visuelle Platzhaltermuster verwenden, aber stattdessen echte Labels.“
und nichts über Best Practices erwähnt.
Ich bin mir nicht sicher, ob ich den Punkt auch verpasse. Aber ich stimme Konstantin zu, warum sollte man Labels als Platzhalter verwenden, wenn man stattdessen den Platzhalter-Attribut verwenden sollte?
Ich hatte mal eine herzzerreißende Geschichte von einem Freund.
Er hat Webarbeit für eine High School für Blinde gemacht. Sie haben viel recherchiert, da es das erste Mal war, dass ihr Unternehmen Webarbeit für ein (offensichtlich) hohes Maß an Barrierefreiheit leistete. Während dieser Recherche haben sie viele Kinder beim Surfen im Web beobachtet.
Einige dieser Kinder gingen nächstes Jahr aufs College und bewarben sich gerade für Colleges. Die meisten Colleges, das macht man online. Webformulare! Einige dieser Webformulare waren so schlecht konstruiert, dass es ihnen buchstäblich unmöglich war zu verstehen, welche Informationen in diese Felder gehören. Hauptsächlich: kein Label, das über die `for`- und `id`-Verbindung an die Eingabe angehängt ist.
Leute boten ihnen Hilfe an, aber sie lehnten wütend ab. Sie gingen aufs *College*. Sie gingen ihren eigenen Weg. Und im allerersten Schritt ihrer Reise brauchten sie eine helfende Hand, weil jemand eine Website gebaut hat, die für manche Leute buchstäblich unbenutzbar ist.
Mein Punkt in diesem Artikel ist, dass Sie das Platzhalter-visuelle Muster mit echten Labels *verwenden können*. Es ist manchmal nützlich, wie ich erwähne, besonders bei Formularen mit sehr wenig Platz oder einem offensichtlichen Muster. Barrierefreiheit muss nicht leiden. Ich stimme auch den Leuten zu, die denken, dass Labels meistens immer sichtbar sein sollten (sowie ordnungsgemäß konstruiert).
Was ist die aktuelle konventionelle Weisheit dazu, wo es gut in die visuellen Design-/Stylingpläne passt, die `for`- und `id`-Verbindung zu überspringen und einfach das `label`-Element um das `input`-Element zu wickeln? Ist das immer noch in Ordnung?
Hier ist meine Sichtweise dazu, und ich stimme Chris fast zu 100% zu, mit vielleicht einer kleinen Einschränkung. Zunächst einmal sind korrekte Labels immer erforderlich, unabhängig davon, ob Sie auch Platzhalter verwenden. Es ist semantisch korrekt und gut für die Barrierefreiheit. René hat es mit seinem Kommentar über „unterschiedliche Zwecke“ am besten ausgedrückt. Es gibt also wirklich zwei Dinge hier
Sollten wir Platzhalter als „Labels“ verwenden (und echte `
Ein weiterer Gedanke
Dies sind wirklich großartige Beispiele dafür, wie HTML und CSS so viel Wert bieten können, noch bevor man mit dem Skripting beginnt. Mein einziger Einwand ist, dass Anweisungen für Formatierung, Passwortgültigkeit usw. immer vor Beginn der Eingabe angezeigt werden sollten, als Teil des Labels oder zumindest vor der Eingabe. Geben Sie den Leuten eine Chance, es auf Anhieb richtig zu machen! Alles andere bedeutet, sie Ihre Anforderungen raten zu lassen und sie dann zu rügen, wenn sie falsch raten.
http://codepen.io/Nice2MeatU/pen/pjEMZR
Hier ist mein Beitrag zu diesem Thema
Leere Felder werden in diesem Pen als ungültig betrachtet (wenn sie erforderlich sind).
Ränder werden bei Fokus blau, wenn das Feld erforderlich ist, und grau, wenn nicht.
Ich muss mich noch ein wenig mit dem Regexp-Kram beschäftigen. Die E-Mail-Validierung funktioniert in den meisten Browsern, aber nicht in allen. Und dann gibt es noch das Problem mit der Unterstützung meiner CSS und der Attribute, wie im Artikel hier erwähnt.
Ein weiterer Pro-Tipp: `<label>`-Elemente sind die besten Kandidaten für „Semantik“ in Bezug auf Fehlermeldungen bei der Formularvalidierung. Das Verhältnis von Label zu Eingabeelement ist *viele zu eins*.
https://stackoverflow.com/questions/6014544/which-is-more-semantic-html-for-error-messages#6014665
Danke Chris für Codepen. Dieses Muster gefällt mir sehr.
Wie wäre es damit mit schwebenden Labels? Für die Benutzerfreundlichkeit ist es meiner Meinung nach immer eine gute Idee (besonders bei langen Formularen), die Labels beizubehalten.
http://codepen.io/brentrobbins/pen/beexQR
Lustiger Zufall, hier ist ein neuer Medium-Post über problematische Platzhalter für Formulareingaben
https://medium.com/simple-human/10-reasons-why-placeholders-are-problematic-f8079412b960#.n97i6ghsy
Mir war nicht bewusst, dass die E-Mail-Überprüfung des Browsers so leicht ausgetrickst werden kann.
name@domain
reicht aus, um alle getesteten Browser zufriedenzustellen.
Das Hinzufügen eines `pattern`-Attributs hilft.
Glücklicherweise ist der Browser nicht so streng wie du, sonst könnte ich mehrere gültige E-Mail-Adressen nicht registrieren. Erstens: Es gibt viele TLDs, die länger als 3 Zeichen sind. Zweitens: Der Domain-Teil kann etwas wie eine IP sein. Drittens: Die Domain kann sogar nur die TLD oder localhost sein.
Ich weiß nicht, was vor dem @ erlaubt ist, aber ich vermute, dass viel mehr erlaubt ist.
Ja René, diese Regex ist schlecht, ich habe einfach die erste genommen, die mir bei Google aufgefallen ist. Aber das ist nicht mein Punkt. Ich denke, aus UI-Sicht ist es verwirrend, wenn eine offensichtlich falsche E-Mail-Adresse mit einem Häkchen validiert wird. Wenn du Google genug strapazierst, findest du eine RFC 5322 konforme Regex. Oder – um den anderen Weg zu gehen – du kannst etwas verwenden, das nur geringfügig besser ist als das, was Browser verwenden (z. B. erfordert ein @ und einen Punkt).
Die vollständige Regex klingt gut, ist aber viel zu aufwendig. Und das Erfordern eines Punktes ist immer noch falsch.
Wiki bietet eine schöne Liste von Do's und Don'ts: https://en.wikipedia.org/wiki/Email_address#Examples
Jenseits des Programmierpunkts
Pflichtfelder und Typumwandlung sollten nur als **Hinweis für Benutzer** betrachtet werden, dass sie Felder ausfüllen sollen. Alles andere ist Selbstbetrug. Sie können alles so gut überprüfen, wie Sie möchten, sowohl client- als auch serverseitig, aber ein Benutzer kann immer noch gefälschte E-Mail-Adressen verwenden, wenn er etwas falsch machen möchte. Selbst das Senden einer Bestätigungs-E-Mail kann mit einem temporären Postfach ausgetrickst werden.
Was die Browser implementiert haben, ist eine großartige Möglichkeit für **Benutzer**, zu sehen, ob sie etwas falsch eingegeben haben. Zum Beispiel, wenn sie einen Namen in das E-Mail-Feld eingeben.
Sie könnten sagen, dass eine bessere Regex Benutzern helfen würde, Tippfehler zu finden, aber ich bezweifle ernsthaft, dass ein fehlender Punkt ein häufigerer Tippfehler ist als alle anderen Buchstabentippfehler zusammen. Zumindest nicht in unseren Datenbanken.
Entschuldigung, falls mein Beitrag aggressiv gegenüber Ihrem wirkt, er ist eher allgemein gemeint. Ich habe einfach eine starke Meinung zu diesem Thema. Genährt von vielen Websites, auf denen die Validierung sehr, sehr falsch verwendet wird. Wahrscheinlich von Programmierern, die davon ausgehen, dass eine E-Mail-Adresse immer [email protected] ist oder jede Postadresse in jedem Land nur einen Straßennamen und eine Hausnummer enthält. Ganz zu schweigen von Postleitzahlen...
Tolle Lektüre, danke! Während ich die schwierige Situation verstehe, geht es doch um die Benutzererfahrung. Wir können nicht gestört und verärgert sein über verschiedene Kombinationen von Lösungen, die mit Sicherheit zu einer positiven Kommunikationslösung führen werden. Daher die unterschiedlichen Lösungen für viele verschiedene Dinge. Mehr Artikel wie diesen bitte!
Danke für den Wikipedia-Link! Mir war nicht bewusst, dass name@domain tatsächlich eine gültige Adresse IST. Aber ich glaube immer noch, dass ein Häkchen, das erscheint, während ich meine E-Mail-Adresse halb eingetippt habe, nicht hilfreich, sogar verwirrend ist.
In diesem Fall scheint es mir besser zu sein, die Browser-Validierung durch JavaScript zu ersetzen, die beim `onBlur`-Ereignis greift. Oder Alex Zaworskis Vorschlag mit einer Übergangsverzögerung von 1 Sekunde oder mehr zu verwenden. Ich war verblüfft, als ich meine E-Mail-Adresse in das Testformular eingegeben habe, und das ist normalerweise ein Hinweis darauf, dass andere Benutzer dies möglicherweise auch tun.
Ich stimme vollkommen zu, dass E-Mail-Felder in vielen Formularen schlechte Regex verwenden. Viele lehnen Adressen mit Pluszeichen ab, die ich oft verwende, und niemand möchte jedes Mal JavaScript deaktivieren, um ein Formular mit schlechter Validierung auszufüllen.
Hä? Klar gibt es den. Mach einfach `document.querySelector(":placeholder-shown");`. Wenn es unterstützt wird, wirft es keinen `SyntaxError`.
Getestet in Firefox, Edge und IE11.
Gefällt mir. Ich habe ein Problem, und zwar, dass meine Labels nicht klickbar sind wie in den Demos hier, obwohl mein Formular die gleiche Grundstruktur hat. Der einzige sichtbare Unterschied in den Stilen zwischen der Demo und meiner Einrichtung ist, dass meine Labels eine `display`-Eigenschaft haben (Änderungen daran haben keine Auswirkungen auf das Verhalten).
Was könnte das Ergebnis eines Klicks auf ein Label-Element wie dieses beeinflussen?
Anstatt `:placeholder-shown`, das anscheinend nicht weit verbreitet ist, warum nicht mit JavaScript erkennen, ob das Eingabefeld einen Wert hat? Etwas wie das hier sollte den Trick machen (ich benutze JQuery, weil ich damit vertraut bin, aber es ist nicht unbedingt notwendig)
Platzhaltertext in Feldern ist eine schlechte Idee. Punkt.
Es spielt keine Rolle, ob sie semantisch Labels oder Platzhalter sind. Sie haben zahlreiche Probleme, wie Adam Silvers Artikel – von Brent gepostet – zeigt (https://medium.com/simple-human/10-reasons-why-placeholders-are-problematic-f8079412b960#.ns8cs1dfz).
Besorgniserregend ist, dass die Tatsache, dass der anerkannte Chris Coyier diese Technik gepostet hat, wahrscheinlich zur Fortsetzung dieses schrecklichen Web-Trends beitragen wird.
Es geht nicht um Designer gegen Entwickler gegen Barrierefreiheit. **Es geht um Benutzererfahrung, für *alle***. Und es sei denn, Sie müssen es unbedingt tun – was sehr selten vorkommt – sollten Sie **niemals** Platzhaltertext in Feldern haben.
Weitere Probleme mit dem, was Chris präsentiert
eingebaute HTML5-Validierungsnachrichten sind schlecht formuliert und gestaltet und sollten wie die Pest vermieden werden
manchmal ist das Einzige, was auf einen Validierungsfehler hinweist, eine rosafarbene Schattierung, die unzugänglich ist.
Ich unterstütze, was andere bereits in den Kommentaren gesagt haben: Nur weil man etwas tun *kann*, heißt das nicht, dass man es tun *sollte*. Das macht es umso wichtiger, dass führende Persönlichkeiten in unserer Community vorsichtig sind, was sie vorschlagen.
Ich stimme Jessica in allem vollkommen zu.
Es macht mich extrem traurig zu sehen, wie Entwickler und Designer ihre wertvolle Zeit mit etwas verschwenden, das eine so schlechte Idee ist.
Bitte: Es gibt noch so viele andere Dinge, an denen wir Ihre Arbeit brauchen. Warum nicht stattdessen eine barrierefreie Auto-Vervollständigungs-Box erstellen?
Denken Sie immer daran: Haben Sie niemals Platzhaltertext in Feldern.