41–50 of 80 posts
Earlier quoted context omitted.
Client side and server side validations need (should!) not be the same — i'd make serverside validation stricter. Client side is for eliminating honest mistakes not preflighting exploits.
Could you give an off the top of your head example?
A hack attempt may be a direct POST circumventing any client side checks.
The implementation just smacks of AngularJS. In fact, implementing something like this would be just short of trivial using Angular...! If you like the concept of "extending html" as used here then you should probably checkout AngularJS: http://angularjs.org
Sometimes you just don't have or don't need angular or other js framework and just simply want to validate a form ;)
Why use rather than... ? You're already using HTML5 data attributes, so why not use HTML5 input types? Added benefit is that the browser also has an idea of what kind of data goes there - this helps on mobile devices especially, where email fields won't auto-capitalize and might include extra buttons like the ".com" button and "@" right on the normal keyboard.
jQuery/Zepto $.data() was fast and easy to implement, rather than searching html5 attr.
I'll think about that ;)
The url validation seems a bit strict, requiring " http:// at the start. No one types that these days, and I think in practice it might be a real roadblock for less computer literate users. I notice also that "ftp://" is valid, but not other protocols like, say, "afp://" or "git://". Other than that, great job! I'm actually really looking forward to using this in my next project - form validation is usually such a pa…
Looks cool, but the demo right at the top of the "examples" page has two things that IMHO aren't as "UX aware" as described on the landing page: - The "website" field requires the http:// part of the address - After typing three letters into the "message" fieldarea, an error pops up and tells me the message needs to be at least 20 characters long, while I'm still typing away I realize this could be tweaked by the use…
Great. How about internationalization? Do you allow to replace the english error messages with messages in other languages?
That is what I came here to ask. Is there way to define the error messages somewhere, per language?
I'll look definitely into a more handy solution soon :)
Typo in the "Super Free" section on the home page: s/developped/developed
Earlier quoted context omitted.
That is what I came here to ask. Is there way to define the error messages somewhere, per language?
Yes, not very handy currently, but you could override all messages in Parsley constructor on each form.. I'll look definitely into a more handy solution soon :)