26562 2014-08-12 18:21:24 +0000 The IDL for createImageBitmap seems to be wrong 2014-09-17 22:43:12 +0000 1 1 1 Unclassified WHATWG HTML unspecified PC All RESOLVED FIXED P2 normal Unsorted 1 ehsan ian bzbarsky ian mike contributor oldest_to_newest 110105 0 ehsan 2014-08-12 18:21:24 +0000 From the prose it seems like the spec is trying to only allow calling this function with 1 or 5 arguments, so the IDL should be something along the lines of: Promise<ImageBitmap> createImageBitmap(ImageBitmapSource image); Promise<ImageBitmap> createImageBitmap(ImageBitmapSource image, long sx, long sy, long sw, long sh); 110253 1 ian 2014-08-18 20:42:24 +0000 You sure? I thought "optional" as used here did exactly what I wanted, i.e. the same as what you list. 110262 2 ehsan 2014-08-18 21:07:51 +0000 I can't find anything in http://heycam.github.io/webidl/ to suggest that it would work like that. 110380 3 bzbarsky 2014-08-21 05:08:02 +0000 In Web IDL as currently specified, I believe doing this: void foo(optional long a, long b); will construct an effective overload set with only one element, since it will immediately run into a non-optional argument. Therefore only a call with 2 arguments will be allowed. Similarly, in the createImageBitmap spec as currently written only calls with 5 arguments are allowed. Unless I'm totally misreading http://heycam.github.io/webidl/#dfn-effective-overload-set somehow, of course... 110553 4 ian 2014-08-25 20:47:07 +0000 Well in that case WebIDL should either ban that case or make it work like I describe... 110557 5 ehsan 2014-08-25 21:11:33 +0000 I think it should be banned. The behavior you're describing is totally non-intuitive. :) 110572 6 bzbarsky 2014-08-26 04:12:36 +0000 IDL very purposefully _allowed_ this case to align more closely with how arguments work in ES. Keep in mind that "optional" in IDL right now doesn't just mean "can be omitted". It also means "can have undefined explicitly passed to mean the argument is missing". So there is a practical difference between these two methods: void foo(optional long a, long b); void bar(long a, long b); both expect to be called with two arguments, but the former allows passing undefined for the first argument and treats that as "not passed", while the latter coerces undefined to 0. Or to make it more interesting: void foo(optional Node a, long b); void bar(Node a, long b); the second method requires a Node as the first argument while the first one will accept a Node or undefined, with the latter meaning "no node". 110624 7 ian 2014-08-26 17:55:59 +0000 That's highly unintuitive to me. I think a [TreatUndefinedAsUndefined] annotation would be clearer. 110633 8 bzbarsky 2014-08-26 18:01:22 +0000 The current setup is basically where we ended up after a bunch of public-script-coord discussion with the ES folks. 111722 9 ian 2014-09-17 22:42:59 +0000 Well I still think the definition of 'optional' here is unintuitive, but I've updated the spec to avoid this case by never having non-optional arguments after optional ones. 111723 10 contributor 2014-09-17 22:43:12 +0000 Checked in as WHATWG revision r8783. Check-in comment: Fix IDL blocks due to my misunderstanding what 'optional' meant https://html5.org/tools/web-apps-tracker?from=8782&to=8783