This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23573 - Drop maxlength="" and minlength="" on <input type=email>
Summary: Drop maxlength="" and minlength="" on <input type=email>
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Needs Research
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard: blocked waiting for data from Kent, p...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-21 03:20 UTC by Kent Tamura
Modified: 2014-01-27 19:08 UTC (History)
8 users (show)

See Also:

Attachments

Description Kent Tamura 2013-10-21 03:20:14 UTC 
Proposal: Remove maxlength/minlength attribute support for type=email

* No good usecases.

* Needs extra implementation cost because of IDN.

* UAs can't show the detailed validation message for tooLong/tooShort
Chrome and Firefox show the following message for type=text:

> Please shorten this text to $MAX_CHARACTERS characters or less (you are currently using $CURRENT_LENGTH characters).

Showing numbers like $MAX_CHARACTERS and $CURRENT_LENGTH for type=email is useless  because of IDN, and UAs need to show an abstract message.
Comment 1 Ian 'Hixie' Hickson 2013-10-21 21:38:34 UTC 
Yeah, that's a good point.

The original use case was servers that have a server-side limitation. What do you propose they do instead? Maybe I can include suitable advice in the spec for authors facing such limitations.
Comment 2 Kent Tamura 2013-10-25 00:11:13 UTC 
Yeah, it's possible that adding maxlength for a sever-side limitation. However I haven't seen actual instances of input[type=email][maxlength]. I'm afraid maxlength solves non-existent problem.

Ok, I'll add usage-counting code of input[type=email][maxlength] to Google Chrome, and will report the result a few months later.

I think minlength is really useless for type=email.
Comment 3 Ian 'Hixie' Hickson 2013-10-25 23:26:12 UTC 
It's true that I've never seen type=email maxlength...

minlength is there purely because maxlength is. I didn't want there to be a one-off control that happened to only have one of the two or something. It seemed pointlessly complicated.

Seems like a reasonable request. Anyone object?
Comment 4 Aryeh Gregor 2013-10-27 12:03:06 UTC 
Seems reasonable.
Comment 5 Mathias Bynens 2013-10-27 20:55:20 UTC 
Removing it sounds good, but let’s wait for the data (comment #2) before making a decision.
Comment 6 Ian 'Hixie' Hickson 2013-10-28 21:45:09 UTC 
Roger.

Kent, when you have the data please let us know, thanks!
Comment 7 Kent Tamura 2014-01-27 01:55:22 UTC 
It seems removing maxlength support for type=email is not reasonable.


Google Chrome 32 Stable has usage counting code for type=email and maxlength. The result:

Ratio of the number of input[type=email][maxlength]:not([multiple]) to the number of input[type=email]:not([multiple])
        23.8%

Ratio of the number of input[type=email][maxlength][multiple] to the number of input[type=email][multiple]
        0.4%

FYI. Ratio of the number of input[type=email][multiple] to the number of input[type=email]
        0.09%
FYI. Ratio of the number of text inputs with maxlength to the number of text inputs
        30.9%
FYI. Ratio of the number of input[type=password][maxlength] to the number of input[type=password]
        23.0%
Comment 8 Ian 'Hixie' Hickson 2014-01-27 19:08:34 UTC 
:-(

I guess we'll mark this WONTFIX. :-(