on type-specific input fields

[Erik Romijn]

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

[Bruno Renié]

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

> --
> 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.
> To post to this group, send email to django-d...@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/6E0F05BE-D767-44B1-9626-3811758C9D31%40solidlinks.nl.
> For more options, visit https://groups.google.com/d/optout.

[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.

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAB4BXAhKnaforSKrUWBKrzT-LXHjU0njJiAVXK3ODHmtRppVfw%40mail.gmail.com.

[patrickk]

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

[Erik Romijn]

Hello,

I've had another look at this. The novalidate attribute on the form for URL and email fields indeed disables the validation in both Chrome and Safari. For number fields, I can reproduce Patrick's test: Safari will still silently drop the value.

So, for URL and email fields, this issue is resolved by setting novalidate on the form. I think we should document a recommendation for users to add this attribute to their forms, and change the forms in the admin to always include the novalidate attribute, as Bruno suggested.

This does not resolve the issue of Safari silently discarding invalid numbers. I don't see a way to resolve that, other than to revert to the text field. Perhaps this is a Safari bug. I haven't managed to find a standard on what browsers should be doing in this case, but this behaviour seems awful. But even if it is a Safari bug, that wouldn't fix the issue for a while anyways. Overall, I'd rather go for the partial novalidate solution for now, than do nothing at all.

cheers,

Erik

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/85a57447-2978-4a7c-9948-28ab36beddbe%40googlegroups.com.