[whatwg] Constraint validation feedback (various threads)

[Ian Hickson]

On Sun, 13 Feb 2011, Mounir Lamouri wrote:
> > On Wed, 24 Nov 2010, Mounir Lamouri wrote:
> >>
> >> After Firefox 4, we would like to introduce a new flag that will let 
> >> us know if the element's value has been changed by the user (probably 
> >> if the _last_ change has been done by the user). The meaning of this 
> >> flag would be to fix the retro-compatibility issues. Then, an element 
> >> would suffer from being too long if this flag is true and it's value 
> >> length is greater than the maxlength attribute value. In addition, 
> >> users will be able to enter text longer than the maxlength attribute 
> >> for textarea (and maybe input) elements. That way, we would be able 
> >> to fix retro-compatibility issues and provide a better experience to 
> >> the users.
> 
> This proposition is mostly trying to fix a user experience issue: when 
> you have to type a text limited to a given number of characters and at 
> some point you just can't type anymore because you reached this limit, 
> it's really frustrating because you have to constantly remove some text, 
> type until you reach the limit, remove some text again...

True.


> It seems much more interesting to use the constraint validation 
> mechanism we already have to tell the user that the text is actually 
> limited to X characters. With that system, the user will be able to type 
> it's entire text and then easily reduce it to the desired size. Think 
> about how annoying twitter.com would be if the users were not able to 
> type when the text field has reached 140 characters.
> 
> Though, this might not be really helpful for text field which aren't 
> expecting a long text. If this is an issue, maybe we could go for 
> Aryeh's suggestion for <input> [1] and do that one for <textarea> only? 
> But it might be confusing.
> 
> [1] UA shouldn't allow the the text length to be greater than the 
> maxlength value (and assume that the element can't suffer from being too 
> long).

Ok. So basically the proposal here is to change the spec so that instead 
of checking the "dirty value flag" to decide whether an element is 
"suffering from being too long", we check to see if the last edit was done 
by the user, right?


On Thu, 24 Mar 2011, Koji Ishii wrote:
>
> Does that cover the case where multiple characters can be composed to 
> single character?
> 
> I'm thinking the case where undetermined text in CJK input methods tends 
> to be longer and may be shortened once determined, but there may be more 
> cases where text gets shorter as you type.

Maxlength is defined in terms of Unicode codepoints, but the UA is allowed 
to let the user type in more text than the max length.


On Thu, 24 Mar 2011, TAMURA, Kent wrote:
> > 
> > Ok. It seems the best solution is to just remove the "suffering from 
> > being too long" state and simply require that authors not let authors 
> > enter values longer than the maxlength. Right?
> 
> I agree removing tooLong validity.
> 
> Google Chrome 10 has the interactive validation, and is causing some 
> compatibility issues about maxlength. 
> http://www.google.com/support/forum/p/Chrome/thread?tid=4f612fe2abafc365&hl=en

On Fri, 25 Mar 2011, Jonas Sicking wrote:
> 
> I don't think we should remove the tooLong validity check. We've been 
> discussing fixing the horrible UI that browsers currently use when 
> maxlength is in effect.
> 
> The problem is that for something like <input name=tweet maxlength=140> 
> browsers currently prevent you from ever entering more than 140 
> characters. This is terrible UI since it means that if you are half way 
> through a sentence when you reach 140 characters, you have to abort your 
> current train of thought, go edit the existing text to make it shorter, 
> go back to the end to keep writing until you reach 140 characters again, 
> rinse, repeat.
> 
> This is why sites like twitter end up not using maxlength and instead 
> use javascript to implement what they need.
> 
> To address this problem we're planning on making Firefox allow the user 
> to type more than maxlength number of characters, but make the field 
> invalid when that happens. Making it invalid will change the UI as well 
> as prevent submission.

That makes sense.

The compat bugs are just caused by scripts adding characters, basically. 
So if we limit it just to user-dirty that solves the problems.

I've updated the spec accordingly.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'