Normal triggers no more binded after first failure

[Marco-Sulla]

There was an else after if (this._failedOnce). This way the binds on normal triggers were not rebinded if the field has failed once.

[marcandre]

This is intended. We want to bind on either the "normal" trigger, or the "after error" trigger, but not both.
You can always list multiple evens in the triggers, so you can include your normal trigger in the after error if this is causing you an issue.

[Marco-Sulla]

I must say the name of the property, data-parsley-trigger, is highly misunderstandable. It seems the validation is triggered every time the event is fired, and not only if no error was fired before.

IMHO it's more useful to add a data-parsley-trigger-always that binds the events every time.

[marcandre]

I understand your point, but I would suspect that for most cases, the afterFailure events are usually enough. That's the case for the defaults. Which events are you using?

[Marco-Sulla]

Usually input and change for date and select inputs. The fact is that we are using bootstrap datepicker and datetimepicker for dates, and SumoSelect (for old projects) and bootstrap select2 for new ones. I checked the source code of these projects and they triggers only the change event. So data-parsley-trigger-after-failure, that I ignored because I thought data-parsley-trigger was enough, fires nothing because it defaults to the input event only.

I think afterFailure is useful only after a failed submit, but IMHO it's more useful to be immediately informed that the input I compiled is wrong. The majority of modern sites work this way.

PS: I also set Parsley.options.validationThreshold = 0, I think it's much more useful and it's highly confusing that the error is not immediately displayed. An high value is good for text inputs, but for the majority of cases is only a cause of misunderstandings.

[marcandre]

At the risk of sounding not pragmatic enough, I don't want to design an API to circumvent bugs, especially in more or less unmaintained libraries (e.g. I created a PR for select2 more than 2 years ago). Another way to say this is that, assuming we ignore bugs of libraries, there are no use case for the feature you are requesting.

I'm sorry you have issues with the input event, but the fact is, it is the exact event that should be used for validation, so I would recommend to circumvent the issues it by triggering these inputs event yourself instead of the defective libraries. This way, you get closer to how things should work.

Alternatively, set afterFailure to "change input".

BTW, I applaud your effort to improve things (like creating this issue and having this discussion), and I encourage you to voice your support for fixing things that are actually broken, like better browser support or the PR for select2.