W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2008

[whatwg] Web Forms attributes: minlength / autocomplete

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 29 Oct 2008 00:40:11 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0810290028020.1237@hixie.dreamhostps.com>
On Wed, 6 Jun 2007, Sander wrote:
>
> I'd like to see a minlength attribute that can be used on the same 
> elements as the maxlength attribute. The default value can be "0" unless 
> the required atribute is set (in that case it should be >1). The value 
> of the element should be trimmed of spaces at the beginning or the end 
> before validating/submitting (perhaps this could be made optional in 
> which case negative values could be used for the minlength attribute to 
> indicate whether the trimming has to take place or not).

I haven't added this, because I'm not convinced the use cases are as 
compelling as those for maxlength. Maybe we should add this in a future 
version, though, if the feature is found to be needed often enough. (For 
now I'd rather keep things to a minimum to give browser vendors a chance 
to catch up.)


> The autocomplete attribute acts as a boolean, but its values are not 
> consistent to other booleans, being either attributes or variables. Why 
> not use autocomplete="autocomplete" or its minimised form? Is it because 
> it's not the "on" state that is important, but the "off" state. If so, 
> I'd suggest to use "true" or "false" instead or rename the attribute to 
> noautocomplete. If it's a backward compatibilty issue then I suggest 
> both on/off and true/false should be allowed.

I'd love to change that, but we're constrained by legacy implementations.


On Wed, 6 Jun 2007, Sander wrote:
> 
> I see. But we can add true/false as possible (and prefered) values and 
> keep on/off for backward compatibility.

I don't think we want to make things even more complex, especially since 
these new values add nothing and don't work in older browsers.


> Following your argument a of of its specs may not be changed anymore, 
> even though the HTML5 specs are still in working draft.

Yup.


On Wed, 6 Jun 2007, Sander wrote:
> 
> For instance some reference codes, zip codes or telephone numbers have a 
> certain length, but maybe not alway the same notation.
>
> As you know telephone numbers in the Netherlands have 10 digits, but 
> some people prefer to write them all together, and others seperate them, 
> using spacers and/or hyphens. If you want to allow people to write their 
> number in their own fashion (which is a good thing from a usability 
> point of view) then you know the number must be at least 10 characters 
> long. Same for Dutch zip codes that are sometimes written with a space 
> in them and sometimes not, but they're at least 6 characters long.

US ZIP codes are of the form "12345-6789" or "12345" but minlength 
wouldn't help you as much as pattern="" here, since "123456" would be past 
the minimum length but totally bogus.


> Perhaps you want users to come up with a password that's at least 6 
> characters long

Passwords are the only real use case I've seen so far, and while that is 
important, it's not really enough to justify the cost given that there are 
plenty of alternatives for doing this.


[...]

On Thu, 7 Jun 2007, Sander wrote:
> 
> Well, you might wonder whether <input type="range"> adds something to 
> type="number" that is really needed.

It's a different control. That's a major difference. :-)


On Thu, 7 Jun 2007, Kristof Zelechovski wrote:
>
> A pattern with exponential matching time can be used to lock the 
> viewer's browser, potentially making her lose her input in other 
> controls and other windows; that means the pattern attribute must be 
> disabled for restricted sites.

Not at all, the user agent can just detect that a pattern is taking a long 
time to match, just like a browser could detect that a document is 
creating too many <img> elements or whatever.


On Thu, 7 Jun 2007, Anne van Kesteren wrote:
> 
> FWIW: you're wrong. maxlength= was made to truncate (again) because not 
> doing so broke existing content. (Implementation experience coming from 
> Opera implementing the Web Forms 2 specification.)

Could you clarify this? I didn't think we'd decided to truncate, just not 
raise an error on initial values that are too long.


On Thu, 7 Jun 2007, Kristof Zelechovski wrote:
>
> These negative values are a misleading hack in that the input value it 
> should be trimmed in the DOM as well to be consistent.  If you need 
> autotrim, introduce an explicit attribute to this end.  This would make 
> the side effect more explicit.

I have no idea what you're talking about here, sorry.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 28 October 2008 17:40:11 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:06 UTC