hyphenate all data-attribute underscores #248
Merged
Conversation
pre: `data_x_y` turns into `data-x_y`. now: `data_x_y` turns into `data-x-y`.
|
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
hyphenate all data-attribute underscores
netbsd-srcmastr
pushed a commit
to NetBSD/pkgsrc
that referenced
this pull request
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
bloom1
added a commit
to wazo-platform/wazo-ui
that referenced
this pull request
Oct 25, 2019
reason: wtforms 2.2.1 changed the way it handles hyphenization See wtforms/wtforms#248
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
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 withdata- attributes htmlthat 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.