71–80 of 145 posts
This breaks my use case function shorten(text, length) const t = document.createElement('input') t.maxlength = length t.value = text return t.value }
This breaks my use case function shorten(text, length) const t = document.createElement('input') t.maxlength = length t.value = text return t.value }
Earlier quoted context omitted.
Even if you use AJAX forms for logging in or registering (I'd prefer you didn't but whatever), you should still use the proper form validation API for things like this. If you use the proper HTML API for gathering data properly, you're most likely not affected badly functionality wise; only your UI will be affected because the form will refuse to be posted without proper explanation. If the change really does get byp…
>Even if you use AJAX forms for logging in or registering (I'd prefer you didn't but whatever), you should still use the proper form validation API for things like this. You don't even need to use "the proper form validation API". It's as simple as changing your ajax call from an onclick (on the submit button) to an onsubmit (on the form).
I do consider using the HTML5 form validation to be the proper validation API. Browser can do a lot without javascript and relying on their default behaviour is still making use of the validation API.
They should remove maxlength altogether; it breaks the expected behavior of textboses wherein pressing a key when focus is in a textbox inserts the character corresponding to that key.
Earlier quoted context omitted.
...I think it's reasonable for there to be some limit, right? Lest a user submit a 50,000 character password?
Nope. Not reasonable, and likely of no benefit to anyone. That'd be like 50kb... assuming it doesn't cause your hashing algorithm to take a shit causing breakage. 50kb to on one request, sitting pretty much at rest 99.9% of the time, is nothing to even bother with. Most folks should probably spend more time worry about optimizing their own payloads instead of their users [1]. [1] To that point, most people want to sp…
This breaks my use case function shorten(text, length) const t = document.createElement('input') t.maxlength = length t.value = text return t.value }
Something similar was used to parse URLs: https://stackoverflow.com/questions/6168260/how-to-parse-a-u...
Highlights from the bug report[1][2]: - HTML spec allows it; says MAY, not MUST [3] - Affects only user pastes, not javascript edits - Affects all input boxes, not just password ones - New preference editor.truncate_user_pastes can restore old behavior As a developer, I personally find the inconsistent behavior of maxLength unintuitive and am surprised a potentially-breaking change like this didn't have more discussi…
This is a welcome change, but what would make it even more awesome is a little red bar at the last character that fits into the maxlength. A semi-common thing I do is paste a long thing of text into an exerpt text area, let it truncate to maxlength and manually tweak the ending. A little red bar to tell me where it would've gotten truncated would make that still possible, while fixing the dangerous behavior with trun…
From the WHATWG/W3C definitions of the maxlength attribute: > Constraint validation: If an element has a maximum allowed value length, its dirty value flag is true, its value was last changed by a user edit (as opposed to a change made by a script), and the code-unit length of the element’s value is greater than the element’s maximum allowed value length, then the element is suffering from being too long. > User agen…
I also hope it will make at least some developers realise that client-side validation is a bad idea.