> The form cannot be submitted until the user fixes the error, so the server shouldn’t receive an excessively long text or password (a server-side validation has to be put in place anyway.) However, this could potentially affect a front-end implementation if it expects the entered text never to exceed maxlength.
What century are Mozilla living in? Most, even simple forms, don't use <form> elements and submit buttons anymore, they're all aJax. Therefore this workaround will be commonly bypassed.
People can debate if this is a good or bad thing, but ultimately the problem remains: This change will cause unexpected behavior when maxlength-ed stuff no longer obeys on thousands of popular websites.
Even if sites check it server-side, that doesn't mean the user experience isn't substantially degraded relative to obeying HTML standards.
Their justification for this change is nonsensical too:
> This change mainly aims at preventing an unexpectedly truncated password from being saved.
So why not limit it to input type=password? Heck why include textareas in this change, who is using a textarea for a password box?!
What century are Mozilla living in? Most, even simple forms, don't use <form> elements and submit buttons anymore, they're all aJax. Therefore this workaround will be commonly bypassed.
People can debate if this is a good or bad thing, but ultimately the problem remains: This change will cause unexpected behavior when maxlength-ed stuff no longer obeys on thousands of popular websites.
Even if sites check it server-side, that doesn't mean the user experience isn't substantially degraded relative to obeying HTML standards.
Their justification for this change is nonsensical too:
> This change mainly aims at preventing an unexpectedly truncated password from being saved.
So why not limit it to input type=password? Heck why include textareas in this change, who is using a textarea for a password box?!