bzbarsky at MIT.EDU
Thu Jan 30 10:35:49 PST 2014
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.
More information about the es-discuss