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

hyphenate all data-attribute underscores #248

merged 2 commits into from Feb 15, 2016


2 participants

doobeh commented Jan 28, 2016

data-x-y is a much more commonly used naming scheme than data-x_y. Popular frameworks such as Bootstrap contains data-x-y attributes as does Foundation and uikit.

As mentioned in the issue comments— the spec only mentions data-* but its clear from just hitting Google with data- attributes html that all the top examples show multiple hyphenated usage, so in this case I think there's a greater win in building towards the common convention rather then the spec as stated.

doobeh added some commits Jan 28, 2016

hyphenate all data underscores
pre: `data_x_y` turns into `data-x_y`. now: `data_x_y` turns into `data-x-y`.

This comment has been minimized.


crast commented Feb 15, 2016

The main issue was WTForms 2.0 compatibility promise. In other words, not breaking behaviours for the sake of breaking behaviours.

But now that we're on 3.0 preview, I can merge this.

crast added a commit that referenced this pull request Feb 15, 2016

Merge pull request #248 from doobeh/master
hyphenate all data-attribute underscores

@crast crast merged commit c76a96c into wtforms:master Feb 15, 2016

1 of 2 checks passed

coverage/coveralls Coverage decreased (-0.0%) to 99.696%
continuous-integration/travis-ci/pr The Travis CI build passed

ftm pushed a commit to ftm/wtforms that referenced this pull request May 10, 2018

Merge pull request wtforms#248 from doobeh/master
hyphenate all data-attribute underscores

@abulte abulte referenced this pull request Jun 4, 2018


Update wtforms to 2.2 #1713

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Nov 12, 2018

py-wtforms: Update to 2.2.1.
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.
-   :class:`~fields.TimeField` and
    :class:`html5.TimeField <fields.html5.TimeField>` were added.
-   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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment