[whatwg] Input color state: type mismatch

[Mounir Lamouri]

On 03/29/2010 09:49 PM, Aryeh Gregor wrote:
> On Sat, Mar 27, 2010 at 9:48 AM, Mounir Lamouri
> <mounir.lamouri at gmail.com> wrote:
>> It looks like the input color state can't suffer from type mismatch
>> according to the specs but it seems to be the only way to be sure the
>> value is correct. Email and URL states can suffer from type mismatch for
>> the exact same reason.
> 
> It isn't possible for color inputs to suffer from a type mismatch,
> because the spec says "User agents must not allow the user to set the
> value to a string that is not a valid lowercase simple color."  If the
> user somehow selects an invalid color, the UA is required to simply
> refuse it, or auto-correct it somehow.  This doesn't work well with a
> text input, where the user has to type the color incrementally -- I
> guess the UA could decide to not update the script-visible/submitted
> value until the user no longer focuses the form field, and if the
> value isn't valid at that time, it could revert to the previous value.

Indeed, this sentence must be the reason why the input element in the
color state can't suffer from a type mismatch. However, as you said it
may be really difficult to respect this where not using a specific UI. I
do not even see how we can do that reasonably. It's the same issue for
date/time/week/whatever. At least, we can consider number/range to be
doable by blocking letters.
Type mismatch seems to be a clean way to prevent that.

If the specific UI is optional, the specifications should let a descent
implementation without this specific UI.

--
Mounir