Made %s
string formatting tokens optional in field validator error messages.
#99
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.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If an HTML form is unable to convey clearly which error goes with which field then either it is being read by a text-to-speech interface or it is in need of a redesign. In the case of the former, you already have defaults designed for this purpose. In the case of the latter, it's not yours or any library's job to undo a programmer's mistakes. Also, when I make a website for art or video games, I shouldn't and don't need to care whether blind people can use the site.
One of the more natural and flexible ways to render one of your forms is with the following Jade and CSS code:
The result is this:
It may not be the prettiest form but it's user-friendly. This may not be the best way to render it but it's a good one. Overall, it's a pretty good use case. This is what it looks like with the error messages made possible in my branch:
Notice the error message with the field name nowhere in it yet still remaining perfectly descriptive in any kind of browser. The default would be "Does not match password.", which sounds robotic and/or foreign mostly because there are so many better ways to word that.
Granted, I could rename the password field so the message doesn't look so robotic but that restricts the grammar I can use and requires me to access the field's data with bracket syntax whenever I want to use spaces. Not to mention how obfuscatory it is to have such an apparently illogical identifier in your codebase. This kind of constraint also makes your library unsuitable for rendering more than one form within the same form tag - which is sometimes the most modular and maintainable way to design an interface - because of possible name collisions. If I wanted to name a field 'form_0_name', the resulting error message would be remarkably offputting to pretty much all users.