This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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);
You sure? I thought "optional" as used here did exactly what I wanted, i.e. the same as what you list.
I can't find anything in http://heycam.github.io/webidl/ to suggest that it would work like that.
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...
Well in that case WebIDL should either ban that case or make it work like I describe...
I think it should be banned. The behavior you're describing is totally non-intuitive. :)
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".
That's highly unintuitive to me. I think a [TreatUndefinedAsUndefined] annotation would be clearer.
The current setup is basically where we ended up after a bunch of public-script-coord discussion with the ES folks.
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.
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