On 1/30/14 9:40 AM, Boris Zbarsky wrote:
It's not clear to me that the former is true (and in fact, making sure that an ES-style spec is not fundamentally buggy in the "doesn't have the desired behavior" sense is _much_ harder than doing it for a WebIDL spec, in my experience).
Let me give a concrete example, actually. Any web specification that involves asynchronously invoking callbacks from the event loop needs to define the incumbent and entry script settings object used when the callback is invoked. If you use WebIDL callbacks, you get this for free, since those define the behavior for you. I don't see the spec under discussion here defining anything like that; presumably it was just overlooked. Preventing that sort of "overlooked" mistake is one of the major goals we had with WebIDL.
I'm not going to make the absurd claim that WebIDL is perfect. I _will_ claim that we want to make it easier to write web specs that don't make basic mistakes like that. And we want to make it easier to write web specs that use the ES capabilities you describe. A desirable property is that even people who are not intimately familiar with the edge cases of ES and the web platform can write specifications describing some sort of basic functionality without tripping up in all sorts of ways.
The question is how we get there. Constructive ideas are very much welcome. -Boris _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
