Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use HTML5 required attribute for required fields #361

Merged
merged 2 commits into from Nov 12, 2017
Merged

Use HTML5 required attribute for required fields #361

merged 2 commits into from Nov 12, 2017

Conversation

@yggi49
Copy link
Contributor

@yggi49 yggi49 commented Nov 12, 2017

If accepted, this PR will add the HTML5 boolean required attribute to all <input>, <textarea>, and <select> fields that have the required flag set (e.g., if the InputRequired validator is used).

@davidism davidism merged commit bdfad66 into wtforms:master Nov 12, 2017
1 of 2 checks passed
@yggi49 yggi49 deleted the html-required-attribute branch Nov 13, 2017
@AlexScheller
Copy link
Contributor

@AlexScheller AlexScheller commented Jun 3, 2018

Is there a discussion somewhere regarding this new behavior? It seemed from issue #130 and this stack overflow answer that the prevailing opinion was to leave it up to the developer to choose whether to render the required attribute or not.

@davidism
Copy link
Member

@davidism davidism commented Jun 3, 2018

It's now up to the developer to choose not to render it. 😉 required=False will force it not to render, or you can make a widget that doesn't set it. The required attribute prevents a request/response cycle for validation, which is valuable enough to make it the default. You can also prevent the behavior without messing with a lot of code by rendering the novalidate attribute on the form tag (or the formnovalidate attribute on a submit button).

My goal with the 2.2 release was to get it out, and I didn't really focus on documentation. If you'd like to make a PR that adds the reasoning above to the docs, that could be really helpful.

@AlexScheller
Copy link
Contributor

@AlexScheller AlexScheller commented Jun 4, 2018

opened a PR basically just copying your response with a bit of editing. The docs built alright on my end. Hopefully this is similar to what you were looking for.

@miguelgrinberg
Copy link

@miguelgrinberg miguelgrinberg commented Jun 4, 2018

@davidism I would have preferred to make this feature opt-in, not opt-out. While the client-side validation works generally well, it was mentioned to me several times that users of apps that use Flask-Babel to offer several languages find it odd that these client-side validation popups cannot be translated and are in the language of the browser and not the currently selected language for the application.

@href
Copy link

@href href commented Jun 4, 2018

I agree that this should have been opt-in and not opt-out. Especially since there doesn't seem to be a straight-forward way to opt out. novalidate applies to the whole form and not just the required attribute. Presumably, there are other types of validation that you might still want.

@davidism
Copy link
Member

@davidism davidism commented Jun 4, 2018

There appears to be an API for modifying a browser's validation messages, although there could be some support from WTForms or an extension to make using it easier: https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation#Customized_error_messages

@davidism
Copy link
Member

@davidism davidism commented Jun 4, 2018

Turns out WTForms already has the ability to control how a form's fields are rendered. Override a form's Meta with a different render_field method.

class MyForm(Form):
    class Meta:
        def render_field(self, field, render_kw):
            render_kw.setdefault('required', False)
            return super().render_field(field, render_kw)

So I think at this point I'm inclined to leave things as-is.

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Nov 12, 2018
Version 2.2.1
-------------

Released on June 7th, 2018

-   :class:`~fields.StringField` only sets ``data = ''`` when form data
    is empty and an initial value was not provided. This fixes an issue
    where the default value wasn't rendered with the initial form.
    (`#291`_, `#401`_)

.. _#291: wtforms/wtforms#291
.. _#401: wtforms/wtforms#401


Version 2.2
-----------

Released on June 2nd, 2018

-   Merged new and updated translations from the community.
-   Passing ``data_`` args to render a field converts all the
    underscores to hyphens when rendering the HTML attribute, not just
    the first one. ``data_foo_bar`` becomes ``data-foo-bar``. (`#248`_)
-   The :class:`~validators.UUID` validator uses the :class:`uuid.UUID`
    class instead of a regex. (`#251`_)
-   :class:`~fields.SelectField` copies the list of ``choices`` passed
    to it so modifying an instance's choices will not modify the global
    form definition. (`#286`_)
-   Fields call :meth:`~fields.Field.process_formdata` even if the raw
    data is empty. (`#280`_)
-   Added a :class:`~fields.MultipleFileField` to handle a multi-file
    input. :class:`~fields.FileField` continues to handle only one
    value. The underlying :class:`~widgets.FileInput` widget gained a
    ``multiple`` argument. (`#281`_)
-   :class:`~fields.SelectField` choices can contain HTML (MarkupSafe
    ``Markup`` object or equivalent API) and will be rendered properly.
    (`#302`_)
-   :class:`~fields.TimeField` and
    :class:`html5.TimeField <fields.html5.TimeField>` were added.
    (`#254`_)
-   Improved :class:`~validators.Email`. Note that it is still
    unreasonable to validate all emails with a regex and you should
    prefer validating by actually sending an email. (`#294`_)
-   Widgets render the ``required`` attribute when using a validator
    that provides the ``'required'`` flag, such as
    :class:`~validators.DataRequired`. (`#361`_)
-   Fix a compatibility issue with SQLAlchemy 2.1 that caused
    :class:`~ext.sqlalchemy.fields.QuerySelectField` to fail with
    ``ValueError: too many values to unpack``. (`#391`_)

.. _#248: wtforms/wtforms#248
.. _#251: wtforms/wtforms#251
.. _#254: wtforms/wtforms#254
.. _#280: wtforms/wtforms#280
.. _#281: wtforms/wtforms#281
.. _#286: wtforms/wtforms#286
.. _#294: wtforms/wtforms#294
.. _#302: wtforms/wtforms#302
.. _#361: wtforms/wtforms#361
.. _#391: wtforms/wtforms#391
klssmith added a commit to alphagov/notifications-admin that referenced this issue Feb 23, 2021
WTForms now renders the `required` attribute if there is a validator
such as `DataRequired`. This was flagged in an accessibility audit as
being unnecessary since it doesn't conform to the Design System
recommendations, which state that "all form fields are considered
mandatory when navigating a government service unless otherwise denoted
by the word ‘(optional)’."

This uses the approach here wtforms/wtforms#361
to overwrite the `render_field` method.
klssmith added a commit to alphagov/notifications-admin that referenced this issue Feb 24, 2021
WTForms now renders the `required` attribute if there is a validator
such as `DataRequired`. This was flagged in an accessibility audit as
being unnecessary since it doesn't conform to the Design System
recommendations, which state that "all form fields are considered
mandatory when navigating a government service unless otherwise denoted
by the word ‘(optional)’."

This uses the approach here wtforms/wtforms#361
to overwrite the `render_field` method.
twizzler pushed a commit to bitzesty/notifications-admin that referenced this issue Sep 21, 2021
WTForms now renders the `required` attribute if there is a validator
such as `DataRequired`. This was flagged in an accessibility audit as
being unnecessary since it doesn't conform to the Design System
recommendations, which state that "all form fields are considered
mandatory when navigating a government service unless otherwise denoted
by the word ‘(optional)’."

This uses the approach here wtforms/wtforms#361
to overwrite the `render_field` method.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants