[whatwg] Constraint validation feedback (various threads)

[Mounir Lamouri]

On 11/16/2010 04:35 PM, Anne van Kesteren wrote:
> Actually, that specific problem was addressed long ago based on feedback
> from us:
> 
> "Constraint validation: If an element has a maximum allowed value
> length, and its dirty value flag is true, and the code-point length of
> the element's value is greater than the element's maximum allowed value
> length, then the element is suffering from being too long."
> 
> The "dirty value flag" is only true when the user has edited the control.

I don't think you can change the meaning of the dirty value flag. If it
is set to true only when the user edit the control, this code will not
work correctly anymore:
input.value = "foo";
input.setAttribute('value', 'bar');
input.value will return 'bar' (instead of 'foo') because when setting
the content attribute's value, with a dirty value flag set to false, the
value is set to the content attribute's value according to the specs.

On 11/16/2010 06:47 PM, Aryeh Gregor wrote:
> [[
> Constraint validation: If an element has a maximum allowed value
> length, and its dirty value flag is true, and the code-point length of
> the element's value is greater than the element's maximum allowed
> value length, then the element is suffering from being too long.
>
> User agents may prevent the user from causing the element's value to
> be set to a value whose code-point length is greater than the
> element's maximum allowed value length.
> ]]
>
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-maxlength
>
> with something like
>
> [[
> If an element has a maximum allowed value length, and the code-point
> length of the element's value is greater than or equal to the
> element's maximum allowed length, user agents must prevent the user
> from increasing the code-point length of the element's value.
>
> Note: For historical reasons, maxlength does not impose any
> constraints on an element.  Thus if an element's value is longer than
> its maxlength, such as if a script set it, the form it's in can still
> be submitted, and no error event is fired.
> ]]
>
> and remove the "suffering from being too long" state.  This matches
> current behavior, but doesn't differ much from the current spec in
> practice, because it means the element can never be in an invalid
> state to begin with unless you do it yourself in JavaScript or set a
> too-long value attribute (and the latter is invalid markup).

That would indeed reflect what browsers seem to do but that wouldn't be
a good idea because this UI is really bad for <textarea> at least. When
you type a long text, it's very frustrating to be blocked at some point
and not being able to just write what you had in mind and then reduce
the size.

We (Mozilla) are going to fix that in two steps:
1. For Firefox 4, elements will be valid if the value length is greater
than the maxlength attribute value (IOW, an element will not be able to
suffer from being too long). This is somewhat following Aryeh's suggestion.
2. 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.

Feedback are welcome :)

Thanks,
--
Mounir