I'm not so sure "novalidate" is a viable solution. If you have a DecimalField and you enter "xxx" this is what happens ...
a) With "novalidate" added to the form: The value is being removed from the field and the form is being saved (tested with Firefox and Safari). b) Without "novalidate": The value is being removed with Safari. There is an error message with Firefox. c) Expected behaviour: The form ist not being saved and I get an error message with the field. Best, Patrick Am Mittwoch, 23. Juli 2014 12:15:12 UTC+2 schrieb Aymeric Augustin: > > “novalidate” would solve the problem as far as the admin is concerned. > > I wasn’t very enthusiastic about switching to the HTML5 input types so > early; now that we have them, I’d rather live with them than remove them, > probably to reintroduce them in a later release. > > -- > Aymeric. > > > > On 23 juil. 2014, at 11:47, Bruno Renié <bub...@gmail.com <javascript:>> > wrote: > > > Hi Erik, > > > > I think a more elegant solution than rolling back to TextInput would > > be to promote/document the use of the "novalidate" attribute. In a > > nutshell, '<form action="…" novalidate>' disables client-side > > validation, letting users submit forms regardless of the client > > validation logic while still taking advantage of the HTML5 input > > types. > > > > Browsers support doesn't seem to be an issue as browsers which don't > > support that attribute (iOS, Android browsers) don't prevent form > > submission at all so they already have a "<form novalidate>" behavior. > > > > Cheers, > > Bruno > > > > On Wed, Jul 23, 2014 at 11:34 AM, Erik Romijn <ero...@solidlinks.nl > <javascript:>> wrote: > >> Hello all, > >> > >> Since Django 1.6, the Django form fields for URLs, numbers and email > addresses make use of widgets that use type-specific input fields in their > HTML rendering. So instead of rendering them as <input type="text">, they > now have type="url", type="number" and type="email". This has upsides: for > example, an email field will cause an iPhone to display the email-optimized > keyboard. > >> > >> However, in #23075[1] sehmaschine raised an important issue: this also > causes browsers to apply their own validation to these fields. This causes > a number of issues: > >> > >> * The validation code used by the browser may not match that used in > Django. For example, URLField will accept "example.com", but Chrome's > validation for type="url" will reject it. Safari on the other hand, does > accept it. So there are two validation steps, which may not be equal, and > which may differ per browser. > >> > >> * Error behaviour of browsers is inconsistent. Chrome renders it's own > unstylable error message. Safari, according to comment 3, will simply > remove invalid values, which is a usability disaster in itself, but > avoidable if the field was type="text" as then the form validation would > detect the invalid value, reject it, and provide a proper error message. > >> > >> * Validation timing becomes inconsistent. In the traditional form > validation flow, the user would submit the form, see any errors, and submit > again. With these fields, some of the validation happens before submit, but > some does not. This can be confusing for users. > >> > >> The workaround is to override the widget in ModelForms or admin forms, > and force it to forms.TextInput(). > >> > >> > >> If we leave the situation as is, developers may unexpectedly find that > their users may get validation errors which are different from all others > in content, style and timing (and possibly language), whose criteria do not > match other validation steps for the same data, and all this will work > differently in different browsers. With the Safari behaviour of simply > ignoring invalid values, mentioned by sehmaschine in the ticket, this > becomes even more serious. > >> > >> Therefore, as much as I like using the correct field types, I think > their issues outweigh the current benefits. I propose that we change all > relevant fields to use forms.TextInput() as their default widget, still > allowing a developer to override this with a specific widget if they do > want to use type="number". Ideally, considering the potential impact, I'd > still like to see this changed in 1.7, although I realise it's very very > late for that. > >> > >> In any case, I thought this might be controversial enough to first > bring it up on this list. > >> > >> cheers, > >> Erik > >> > >> > >> [1] https://code.djangoproject.com/ticket/23075 > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "Django developers" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to django-develop...@googlegroups.com <javascript:>. > >> To post to this group, send email to django-d...@googlegroups.com > <javascript:>. > >> Visit this group at http://groups.google.com/group/django-developers. > >> To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/6E0F05BE-D767-44B1-9626-3811758C9D31%40solidlinks.nl. > > > >> For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google > Groups "Django developers" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to django-develop...@googlegroups.com <javascript:>. > > To post to this group, send email to django-d...@googlegroups.com > <javascript:>. > > Visit this group at http://groups.google.com/group/django-developers. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAB4BXAhKnaforSKrUWBKrzT-LXHjU0njJiAVXK3ODHmtRppVfw%40mail.gmail.com. > > > > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/85a57447-2978-4a7c-9948-28ab36beddbe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
