Closed Bug 613016 Opened 14 years ago Closed 7 years ago

When a text field has a maxlength attribute set, the users should be able to put a value longer than maxlength

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: mounir, Unassigned)

References

Details

With HTML5 Forms, the users should be able to set a long value and they will got an error message telling them to reduce the size. It seems to be better for UX.
Blocks: 344614
After discussing with Mounir, I'm preemptively setting this to blocking- as this is a too risky change to do for FF4.
blocking2.0: --- → -
Depends on: 613019
I question this - it's a significant change from HTML 4 behavior.

In classic implementations of HTML 4, when a maxlength is present, the user can't physically type in more characters than that length.  You're proposing changing that, and then making it a validation-only error, I think.  The novalidate attribute on forms would allow it to pass through at any length.

There's something to be said for the browser keeping pre-existing length constraints on data submitted to the server.  (I don't want novalidate to mean I can submit 40KB of data in an input field that had a maxlength of 20, when pre-HTML 5 browsers wouldn't allow that.)  I'm thinking primarily in terms of the size of the HTTP request sent from submission.

Another implication is that maybe the user could type in a lot of data, but then the browser crops it, which is also bad because what the user typed and what went through would be different.

Now, if you said to me "We unconditionally won't allow an overlength text field to submit", I'd probably buy that, but then I'm sure there's a part of the spec saying we might not be able to do that either.
(In reply to comment #2)
> I question this - it's a significant change from HTML 4 behavior.
> 
> In classic implementations of HTML 4, when a maxlength is present, the user
> can't physically type in more characters than that length.  You're proposing
> changing that, and then making it a validation-only error, I think.  The
> novalidate attribute on forms would allow it to pass through at any length.

novalidate has been introduced with HTML5. So, maybe between the release of Firefox 4 and Firefox Next, some websites will use novalidate and maxlength but right now, it doesn't seem to be an issue.

> There's something to be said for the browser keeping pre-existing length
> constraints on data submitted to the server.  (I don't want novalidate to mean
> I can submit 40KB of data in an input field that had a maxlength of 20, when
> pre-HTML 5 browsers wouldn't allow that.)  I'm thinking primarily in terms of
> the size of the HTTP request sent from submission.

This sound much more like an attack than a regular behavior and that could be done even if the input's value length is limited by the UA.
(In reply to comment #0)
> With HTML5 Forms, the users should be able to set a long value and they will
> got an error message telling them to reduce the size. It seems to be better for
> UX.

This sounds like a bug in HTML5. How is this better for UX?
The current UX for maxlength is horrible. Compare to sites like twitter which allow you to enter anything, but lets you know when you've entered too much. It's a pain in the ass to try to trim down a message (or whatever you're entering in the text field) to less than N characters, while at all points in time keeping the length less than N.

For example often you write out the whole message, see if it's short enough, and if it's not step back and edit it to use shorter words etc. Often while doing said editing you end up adding a word and only then removing the word you're replacing.

With our current UX, once you reach maxlength you are hosed. First off you have to abort your train of thought since you can't write it down. Then you have to delete a lot of content before you can add anything. And if you need to experiment with modifications at multiple places to see what works, you have to delete a bunch of stuff first to ensure that what you're typing fits. Generally at that point you're better off just opening a text editor and typing there.

Almost everywhere where I see maxlength being used today is for very short things like phone numbers. I suspect that for anything longer the problems above are so annoying people just hand-craft their own JS validation.

But even for phone numbers here I'm often annoyed by current behavior. For example if I write "08-12 34 56" then realize that maxlength is set preventing me from including spaces. At that point I have to immediately go to the beginning of the text field and remove the parts the site didn't want. Only then I can go to the end and finish typing the numbers that didn't fit before.


All in all, it's much better to allow the user to enter a value in the order he/she wants. Only at the end should we tell him/her that the value wasn't allowed.


The only thing I would do special for maxlength is that I'd say that we should make the field match :-moz-ui-invalid as soon as the length grows longer than the specified length. Rather than once the user moves focus elsewhere like we do for other validation violations.
If you want non-hard maxlength, just use pattern.
What is the use case for "hard" length?

Also, that wouldn't solve the crappy UX on all pages out there that use maxlength.

If we really think pattern should be the only way to get good UI here then we should deprecate maxlength.
Pattern shouldn't be used for that: I think using pattern should be prevented as long as we can given that it can't be interpreted easily (there is no semantic). For example, screen readers might want to use maxlength but wouldn't be able to use pattern.
I wrote this a few days ago, it's an experiment on how maxlength could be implemented:
http://www.fruitsofts.com/testcases/textarea_maxlength.htm

The second textarea has a custom maxlength2 property, and displays the count of actual / allowed chars when it is focused. Maybe browsers could implement something like that ?
I don't think we will implement the box showing the current length and the maxlength. Except that, it corresponds to what we want.
One problem of the box is that it can't be easily styled.
Still, isn't it more usable than just showing some boolean valid / invalid status ?
(In reply to comment #12)
> One problem of the box is that it can't be easily styled.
> Still, isn't it more usable than just showing some boolean valid / invalid
> status ?

In addition of the boolean, there are some pseudo-classes.
I don't think the box would be useful to everyone. That's typically the kind of stuff that should be implemented if needed per authors instead of by default, IMO.
By the way, this bug would fix the issue described here too:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/031022.html

tl;dr: people using CJK input methods need to type a string that is transformed in one character but with maxlength they are sometimes unable to type the entire string.
(In reply to comment #14)
> By the way, this bug would fix the issue described here too:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/031022.html

We don't have this problem. Gecko discards the over characters at committing the composition string. So, until committing, we can input longer text.
Blocks: 595451
No longer blocks: 595451
Keywords: student-project
Whiteboard: [mentor=volkmar]
Blocks: 717600
Keywords: student-project
Whiteboard: [mentor=volkmar]
Note that this change would degrade interop by bringing Firefox out of alignment with all other major modern browsers, which all currently prevent the user from typing characters beyond the maxlength (possibly modulo IME).
Was a decision ever made here? As Chris mentions, other browsers still seem to do what Firefox does (I just confirmed that Chrome and Edge do, at least).
The current behavior is pretty terrible UX. However it's likely better that we give developers the tools to create their own UX, rather than try to improve the built-in HTML form controls to the point where they are actually useful as high-quality controls.

So I suggest we don't spend time on this and instead improve contentEditable to the point where it's usable.
Closing as per comments c16 and c17 - parity with all other major browser, also confirming for Safari using this fiddle https://jsfiddle.net/scheinercc/p8r4ya8z/
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.