- From: Mounir Lamouri <mounir.lamouri@gmail.com>
- Date: Tue, 16 Nov 2010 16:04:08 +0100
> On Thu, 12 Aug 2010, Aryeh Gregor wrote: >> On Wed, Aug 11, 2010 at 6:03 PM, Ian Hickson <ian at hixie.ch> wrote: >>> The script setting the value doesn't set the dirty flag. The only way >>> this could be a problem is if the user edits the control and _then_ >>> the script sets the value to an overlong value. >> >> """ >> value >> On getting, it must return the current value of the element. On >> setting, it must set the element's value to the new value, set the >> element's dirty value flag to true, and then invoke the value >> sanitization algorithm, if the element's type attribute's current >> state defines one. >> """ >> http://www.whatwg.org/specs/web-apps/current-work/#common-input-element-apis >> >> That seems to say that setting via .value will set the dirty flag >> (although setting via .setAttribute() will not). Am I mistaken? > > Hm, yes, you are correct. > > I've lost track of the context for this; does the above imply that there > is a change we need to make? Aryeh was worried about page using maxlength to block users input then setting the value to something else before submitting. Given that maxlength has nothing to do with form validation and now can block the form submission, it might break some websites. There is a LinkedIn form broken because of that: there are two fields with a non-HTML5 placeholder (ie. it's the value) which is set with .value="something" but the field has a maxlength set to 4 (it's a year). With a checkbox checked, one of this field will be hidden, with a value greater than the maxlength making the form always invalid. -- Mounir
Received on Tuesday, 16 November 2010 07:04:08 UTC