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 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.