"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]> 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]> 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]. >> 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/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]. > 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/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/3003CBEE-4D2A-4AB4-8D8F-5D76E6C1C711%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
