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é <[email protected] <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 <[email protected] > <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 [email protected] <javascript:>. > >> To post to this group, send email to [email protected] > <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 [email protected] <javascript:>. > > To post to this group, send email to [email protected] > <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 [email protected]. To post to this group, send email to [email protected]. 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.
