This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
HTML has tons of IDL attributes like [TreatNonCallableAsNull] attribute Function? onabort; Function is actually an interface it defines: http://www.whatwg.org/specs/web-apps/current-work/#function This is very weird, and probably contradicts ES in some details (like whether the .call property of the prototype is configurable). It would make more sense for WebIDL to have a dedicated function type. The algorithm for converting to a function should probably return null if the thing passed in isn't callable, so the above could become just attribute function? onabort; since every single usage of Function? in HTML seems to use [TreatNonCallableAsNull], so it may as well just be the behavior all the time.
This may also be the last remaining use of [Callback=FunctionOnly], so providing a dedicated interface for this would let us kill both FunctionOnly and TreatNonCallableAsNull.
(Note though that this wouldn't let people create event handlers without referencing HTML, as some people would like; see http://www.w3.org/mid/op.v5atfs1x64w2qv@annevk-macbookpro.local )
We now have callbacks in Web IDL, so HTML's Function can be defined as: callback Function = any (any... arguments); This is less weird. I don't think we really need to move it across to Web IDL; the weirdness of the Timer APIs is not something I think we want to propagate to new APIs. Aryeh, let me know if not adding this definition to Web IDL itself is acceptable, thanks.
That seems okay to me. I don't think we need a special "function" type, because in fact most of the users of Function in HTML should get a callback with a specific signature, not just any old function. (It seems to make no actual difference what the signature for the callback is, except that it theoretically guarantees the type of the parameters and puts some constraints on how some return values will behave. But it's still handy as documentation.)