Re: on type-specific input fields
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 On 23 Jul 2014, at 13:15, patrickk <patr...@vonautomatisch.at> wrote: > 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> 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, '' 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 "" behavior. > > > > Cheers, > > Bruno > > > > On Wed, Jul 23, 2014 at 11:34 AM, Erik Romijn <ero...@solidlinks.nl> 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 , 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 ca
Re: on type-specific input fields
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 > > 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, '' 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 "" behavior. > > > > Cheers, > > Bruno > > > > On Wed, Jul 23, 2014 at 11:34 AM, Erik Romijn <ero...@solidlinks.nl > > 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 , 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. > >&
Re: on type-specific input fields
"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é <bubu...@gmail.com> 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, '' 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 "" behavior. > > Cheers, > Bruno > > On Wed, Jul 23, 2014 at 11:34 AM, Erik Romijn <erom...@solidlinks.nl> 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 , 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-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/6E0F05BE-D767-44B1-9626-3811758C9D31%40solidlinks.nl. >>
Re: on type-specific input fields
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, '' 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 "" behavior. Cheers, Bruno On Wed, Jul 23, 2014 at 11:34 AM, Erik Romijn <erom...@solidlinks.nl> 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 , 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-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/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-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/CAB4BXAhKnaforSKrUWBKrzT-LXHjU0njJiAVXK3ODHmtRppVfw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
on type-specific input fields
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 , 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-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/6E0F05BE-D767-44B1-9626-3811758C9D31%40solidlinks.nl. For more options, visit https://groups.google.com/d/optout.
