javascript and maxlength

Bloke · 2014-03-10 15:23:28

Am I going mad? Is the result of this fiddle expected behaviour?

The input control has a maxlength attribute which limits user input to the specified length, but anything written to it programmatically via javascript (or jQuery, by extension) seems to ignore the property. If you try to subsequently edit the text, you cannot add anything to it; only when you make the string shorter than maxlength can you do so.

I tried some cheating jQuery mechanisms like this:

jQuery('#title').val('This is a giant string to see if javascript violates maxlength').keyUp();

(and .change(), .blur(), etc), but no dice. It looks like I’m going to have to do something like this:

jQuery(function () {
    me = jQuery('#title');
    str = 'This is a giant string to see if javascript violates maxlength';
    var max = me.attr('maxlength');
    if (max) {
        me.val(str.substring(0, max));
    } else {
        me.val(str);
    }
});

Unless I’m doing something fundamentally wrong?

Of course, I’m not using fixed strings in my application. This will be part of a loop that reads values via AJAX from remote sources and populates an HTML form with the contents.

Anyone any thoughts on this? I can’t think of any reason why you would want to put more characters in a field than designated, but maybe there’s a good reason for this behaviour?

Any better ways round it? Chrome 33, Firefox 27 and IE 11 all do the same thing, so presumably this is the correct / documented behaviour as per the spec. Or a javascript bug?

etc · 2014-03-10 20:06:54

Bloke wrote #279628:

Or a javascript bug?

Looks more like a feature.

Bloke · 2014-03-10 20:35:17

etc wrote #279635:

Looks more like a feature.

Nice sleuthing, sir. I searched for ages trying to find reference to this phenomena, but just turned up tonnes of documents on how to place size limits on textarea fields using javascript.

If it’s a known “feature” then I guess I have to live with it and work around it. Just found it a bit strange, given the amount of validation options that browsers offer in response to HTML attributes like required, that maxlength was selectively ignored.

I mean, if I (programmatically) empty a required field’s contents, the browser doesn’t just allow the form to be submitted because the input didn’t come from the keyboard, it still flags the problem. The only way round that is to set the field disabled, then it (correctly, imo) ignores the field and any validation rules. But in the maxlength case, I can programmatically write a longer string than is permitted to a field and it still submits the longer string to the server; doesn’t even truncate it on submit or offer a warning. A little inconsistent, but maybe I just haven’t figured a good use cases for allowing this behaviour yet.

etc · 2014-03-10 20:53:32

Bloke wrote #279636:

I mean, if I (programmatically) empty a required field’s contents, the browser doesn’t just allow the form to be submitted because the input didn’t come from the keyboard, it still flags the problem. … But in the maxlength case, I can programmatically write a longer string than is permitted to a field and it still submits the longer string to the server; doesn’t even truncate it on submit or offer a warning.

If you set pattern=".{0,20}", you’ll be warned on form submission. That’s a little inconsistent, indeed.

Textpattern CMS

Textpattern CMS support forum

#1 2014-03-10 15:23:28