@@molily:
nuqneH
Das ist lustig Aussage angesichts dessen, dass man im Safari 5, ein Browser, der Techniken wie required unterstützt, das Prüfen des Formulars, das Anzeigen von Meldungen und das Blocken des Absendens manuell mit JavaScript lösen muss. Meines Wissens ist dieses Verhalten auch HTML5-konform.
“The no-validate state of an element is true if the element is a submit button and the element's formnovalidate attribute is present, or if the element's form owner's novalidate attribute is present, and false otherwise.”
Da hier weder @novalidate noch @formnovalidate im Spiel ist, sollte der Status false sein.
“When a form element form is submitted […]
5. If the scripted-submit flag is not set, and the submitter element's no-validate state is false, then interactively validate the constraints of form and examine the result: if the result is negative (the constraint validation concluded that there were invalid fields and probably informed the user of this) then abort these steps.”
Wie ich das lese, darf ein nicht korrekt ausgefülltes Formular nicht abgeschickt werden. Demnach wäre das Verhalten des Safari nicht HTML5-konform …
Im Firefox und Chrome hingegen wird das submit-Ereignis nicht gefeuert, wenn das Formular Fehler aufweist und browsereigene Fehlermeldungen angezeigt werden.
… sondern jenes von Firefox und Chrome.
Damit eine konsistente UX umzusetzen, die dem Nutzer hilfreiche Hinweise gibt, ist nicht ohne JavaScript-Quirks möglich.
Oh je, immer noch browserspezifische Eigenbrödlerei statt Standardkonformität. Browserkrieg 2.0.
Na dann schickt Safari eben auch das Formular ab und bekommt die Fehlermeldungen vom Server – vorläufig, bis Apple den Bug gefixt hat.
Da würde ich lieber auf HTML5-Formularvalidierung verzichten und client- wie serverseitig eine eigene zuverlässige umsetzen.
Warum sollte man den fähigen Browsern die performante Lösung vorenthalten?
Qapla'
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)