Add HTML5 required attribute on form widgets

[Jon Dufresne]

Hi,

I'm working on ticket #22383 to add the HTML5 required attribute to form widgets.

The hope is this will add an additional level of validation at the client side. The feedback provided to the user is much faster than a server round trip.

This is something I've done manually in my own projects. I'll frequently add "required" to widget attrs to take advantage of this validation. As I already use this frequently, I'm motivated to see it adopted by the Django core.

This feature have been discussed in the ticket [1] as well as a previous email thread [2].

In the past, there were two discussed concerns:

* Allow a project to opt-out of using the required attribute

* Add a deprecation warning that new version of Django will include the required attribute

Past discussion settled on using the class attribute Form.use_required_attribute to decide if a form's widget should render the HTML5 required attribute. As this was the previous consensus I have implemented a PR [3]. To be on the safe side, this PR also adds the deprecation warning.

Upon review, Tim Graham replied with the following:

I fear the deprecation will be quite annoying if every form in a project needs to be modified to silence all warnings.
...
I guess I'm not sure if a deprecation path provides more value than making a backwards-incompatible change. For example, if we expect a majority of projects to adopt this change, then a deprecation will require every Django project to silence the warning instead of a subset of users to opt-out.

No problem for me. I'm OK skipping the deprecation path. I don't see it as necessary, I was simply trying to accommodate other opinions. I have created a second PR which is identical to the first, but without the deprecation warning [4].

Also in the review Tim suggested the following:

I wonder if template-based widget rendering (#15667) might ease this change. A project could provide custom widget templates if they don't want the required attribute (or if they want required='required'.

This is a different approach than previously discussed. I see the merit in this suggestion and think it could be a better implementation. With this idea, we could avoid adding the Form.use_required_attribute, entirely. However, template-based widget is still very much a WIP. I worry waiting on that feature may mean this simpler feature may miss a release cycle. Is it reasonable to expect the template-based widget rendering to land before the next alpha/beta cut?

Tim asked I post these ideas to the mailing to get other opinions and feedback on these two points.

Thanks,

Jon

[1] https://code.djangoproject.com/ticket/22383
[2] https://groups.google.com/forum/#!topic/django-developers/obw18wSc4xU/discussion
[3] https://github.com/django/django/pull/6341
[4] https://github.com/django/django/pull/6352

[Collin Anderson]

Hi All,

I think things are kind of quiet because djangocon.eu is starting tomorrow.

My opinion: In the past we changed things to use html5 types (number, email, url, etc) and we didn't use a deprecation warning in those cases, just mentioned it in the release notes. I'm sure it will break some people's applications, but I think as long as we made it easy to remove the required attribute it shouldn't be a big problem to not warn first.

Thanks,

Collin

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADhq2b7z08aYuY_wpzCCkCaEfOAT5uQvh74wsPCJoZT0hF5aGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Riina]

What's the plan for formsets with extra?

I could see the required only getting applied to the first min forms but I'm not sure there is an actual workable case there. It seems like it will get too messy with adding and deleting at the same time.

If can_delete is false and extra is 0, it seems like the required attribute could at least be used. Because of this, I think it should probably be an initialization argument, default to false, or be overridden when constructing forms in formsets.

https://github.com/gregmuellegger/django-floppyforms/issues/75

[Jon Dufresne]

Thanks for highlighting this.

I'll investigate implementing the suggestion "If can_delete is false and extra is 0, it seems like the required attribute could at least be used. Because of this, I think it should probably be an initialization argument, default to false, or be overridden when constructing forms in formsets." Thanks.

I think with this concern, this feature can't be solved entirely by template-base widgets as something other then Field.required is necessary for the formset case.

Cheers,

Jon

[Collin Anderson]

If anyone is running into hidden required fields preventing forms from submitting (like me), I've been using this jQuery code for a somewhat-hacky quickfix:

$(':hidden[required]').removeAttr('required')

[Jon Dufresne]

On Thu, May 5, 2016 at 11:29 AM, Collin Anderson <cmawe...@gmail.com> wrote:

If anyone is running into hidden required fields preventing forms from submitting (like me), I've been using this jQuery code for a somewhat-hacky quickfix:

$(':hidden[required]').removeAttr('required')

The changes made on master should not be adding required to hidden inputs. I added a check to prevent this. Are you experiencing different?

Are these inputs hidden by Django or from another source?

Cheers,

Jon

[Collin Anderson]

Hi Jon,

They're regular input fields that I'm using jQuery to .hide() and .show() form fields on the front end of my ecommerce sites, based on different radio buttons. It's all my jQuery code. I then have custom logic in the backend to delete fields from forms, or select which form to validate against. (Login vs Create account, Checkout vs Apply promo code, Use a saved address or add new address, etc.)

Thanks,

Collin

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.

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