[whatwg] The type mismatch validity flag

Brian Wilson brian at opera.com
Wed Dec 8 10:02:30 PST 2004

On Wed, 08 Dec 2004 10:09:59 +0100, Olav Junker Kjær <olav at olav.dk> wrote:

> Brian Wilson wrote:
>  > This would seem to indicate that a type mismatch validity flag
>  > condition can only be triggered by *manual* widget input.
> ...
>  > It does make several of my automated test cases unusable though. Drat.
> You could set the value through script and validate() afterwards, you  
> can do that automatically.
> But that raises an interesting point: If an invalid value is sat through  
> script, should the value be displayed or ignored? With some widgets,  
> like a slider, there is no way to display invalid values, so it would  
> have to be ignored (and the value reset).
> Maybe this should be implementation dependent, since the range of  
> invalid values which is displayable depends on the widget.

I've been reading this:

> In section 2.18, the following is found:
> For value attributes that are invalid according to the type attribute
>   The attribute must be ignored. It will appear in the DOM for the
>   defaultValue attribute, but will not be used as the value of the  
> control.
>   The control will therefore initially be empty.

as being applicable in the value-set-by-script case. The statement seems  
to be agnostic over whether the value is set by script or by page load.  
Some widgets, like the slider widget, will *most likely* not provide a  
user with the capability to go against domain type (the proposed widgets  
I've seen thus far don't seem to allow it, but anything is possible).

The spec can not guarantee that any widget will have a UI that enforces  
domain constraints, so it should probably explicitly state expected  
behavior in those cases (the above text doesn't appear to satisfy this  


Brian Wilson
Opera Core QA

More information about the whatwg mailing list