That's their justification, not a restriction on the change, this impacts non-password fields too.

Yeah that's the weird thing. They write "for password fields" and then apply it to non-password fields and even multi-line fields. Have you ever seen a multi-line password field?! I understand that people might abuse <textarea> for it but that's definitely not the common thing and just crazy talk. It's an excuse but I don't understand the reason behind this change.

I've been setting maxlength to generous values on my fields in applications since I started coding HTML, if now suddenly I have to revisit everything and add JavaScript magic to check form validity where previously the page was completely free of JS, well, I think I'd frankly refuse where possible and tell people to complain to their faulty implementation.

At the risk of stating the obvious, and sorry if so: doing input length validation client side is very useful for the user's experience, but the server should always validate this too. "... now suddenly I have to revisit everything and add JavaScript magic to check form validity ..." sounds suspiciously like you were relying on client side form validation without server validation, I hope that's not the case. :)

It prevents server-side errors, which I don't handle as gracefully. When the client sends content that it shouldn't have been able to send (i.e. someone tampered with the form) and the server bails out, I don't always bother making it pretty.

I'm well aware of the risks in client-side validation, but indeed, as I see in my job often enough (I'm a security consultant), it's a valid remark that not everyone has taken to heart quite yet so thanks for the comment :)

Ah yes, preventing uglier server-side errors is indeed a very valid reason. :)

Eh? For what reason you need to add JS? Forms won't submit with overlong text.

Oh the change is that it'll not cut the user off but show a warning instead? I misread the post then.

Edit: Yes, indeed:

> The form cannot be submitted until the user fixes the error, so the server shouldn’t receive an excessively long text

Thanks for pointing that out!

I imagine the goal is to make behavior consistent instead of adding weird exceptions.