[Bug 19936] consider allowing non-matching enums to be converted to a particular value

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19936

--- Comment #10 from Jan-Ivar Bruaroey [:jib] <jib@mozilla.com> ---
(In reply to Cameron McCormack from comment #8)
> For HTMLCanvasElement.getContext, I'm thinking now that a DOMString
> expresses the intent better: context names can be any string, and the
> defined behaviour of getContext is to return null for a context type it
> doesn't support.

Except there are only a few defined and implemented values: "2d",
"experimental-webgl" and "webgl". I think in c++ this would have been an enum.
To add another value, we'd add another value and recompile everything (because
that's c++), and we'd get more structured documentation.

Thank goodness getContext only has three values: 
https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement#Methods

> For HTMLInputElement.type (an IDL attribute "limited to only known values"),
> assigning any string causes the content attribute to be given that value,
> but getting its value will only the default value (or the empty string for
> some) if the value of the content attribute is not valid.  The behaviour
> here seems a bit different from HTMLCanvasElement.getContext.

Having behavior - or how a type is used - influence the validity checking of
the type, seems bound to break down since the same type may be used in several
places.

Shouldn't the same typing apply regardless of which mechanism I use? Right now
I don't see the rationale for why:

  Foo.type = "blah";               // doesn't throw.
  Foo.setType("blah");             // throws.
  var x = new Foo({type: "blah"}); // throws.

when they're all trying to do the same thing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 11 September 2014 07:13:54 UTC