3 ms·
You gotta be careful about going overboard with it. Recently I was trying to get a refund on Groupon because the company I'd bought a Groupon for was under new
by donatj 2y ago
You gotta be careful about going overboard with it.
Recently I was trying to get a refund on Groupon because the company I'd bought a Groupon for was under new management that refused to honor my groupon.
The form had a stipulation "minimum of 15 words". Try as I might, I could not get the form to pass validate until I inspected the HTML.
<input pattern="^(\b\w+\b\s*){15,}$" required>
\w - word characters
\b - word boundaries
\s - white
Literally zero allowance for any sort of punctuation.
- recursive 2y agoI don't think this is particularly pertinent to HTML validation. This is true of any type of validation. The same rule could have been applied on the server, and then you would have had no hope.
- whoisthemachine 2y agoExactly. My rule of thumb is "don't add validation until there is absolutely no better way and you absolutely must restrict this input."
- everdimension 2y agoThat's actually a good argument for the point I was trying to make. Existing validity attributes such as "pattern" are cool, but not enough. E.g. the "repeat password" example is actually achievable without "setCustomValidity" by using the "pattern" attribute. For that, you would have to dynamically construct a RegEx out of the value from the first input. I didn't want to make the article too long by comparing the solutions, but the point is, with the "customValidity" you see how much more eloquent and easier to read the validation is. So a nicer API here makes all the difference The "15 word minimum" constraint would look so much nicer as "value.split(/\s+/).length >= 15".