Hacker News Reader

Comment by donatj | Hacker News Reader

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.

View on HN

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

Exactly. My rule of thumb is "don't add validation until there is absolutely no better way and you absolutely must restrict this input."

That'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".

Reply on news.ycombinator.com