[whatwg] Constraint validation feedback (various threads)

On Mon, Nov 15, 2010 at 9:05 PM, Ian Hickson <ian at hixie.ch> wrote:
> 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?

maxlength should either not block submission at all, or only block
submission when the user (not a script) was the last one to edit it.
Currently it blocks submission even when a script set the value,
consistent with other new validation constraints but inconsistent with
legacy behavior.  The two solutions are mostly equivalent given how
browsers implement maxlength UI in practice, but differ in edge cases
like

data:text/html,<!doctype html><form>
<input maxlength=1 onfocus="this.value = 'abc'">
<input type=submit>
</form>

If you focus the form and hit backspace once, legacy behavior is to
permit submission of the form, but HTML5 behavior is to prohibit it.
It might be okay to keep HTML5 behavior in this case, but I don't see
the point.  I think the easiest change is to replace

[[
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).

Received on Tuesday, 16 November 2010 09:47:23 UTC