On 22/01/2012, at 21:00, Brendan Eich wrote:
>> Brandon Benvie <mailto:[email protected]>
>> January 21, 2012 9:59 PM
>> Sorry to spam this thread but I wanted to get the relevent points in up 
>> front:
>> 
>> 'Actually, wait a minute -- I think I disagree with you here.
> 
> On what? Being past the deadline? Not rushing a de-jure standard before we 
> have synthesized the right semantics from relevant JS embeddings?
> 
>> Spec the unofficial agreement, including the minimal(/maximal if it exists) 
>> time constraints, and go from there. This is needed.
> 
> Why? What goes wrong if we go light on execution model one more time? I think 
> nothing.
> 
> But in fact we are going to get a little more into execution model in ES6. 
> How much remains to be seen. We discussed it at last week's meeting.
> 
> But this is not an all-or-nothing proposition, and I do not see the do-or-die 
> requirement. Reality is what it is. HTML5 captures a lot. Node.js conforms. 
> ES6 saying more doesn't alter these facts.

Now isn't that ~ the opposite of what you said on 2011-03-18 in David Bruants' 
"Bringing setTimeout to ECMAScript" thread ?

<quote>
Add to that the fact that Netscape and Microsoft failed, or chose not to, 
standardize the DOM level 0, and we have the current split where setTimeout is 
in HTML5 but the core language is embedded with increasing success in 
non-browser, no-DOM host environments *that want setTimeout*.

I'm open to Ecma TC39 absorbing setTimeout and the minimum machinery it 
entrains. We should ping Hixie.
</quote>

Why ?
What has changed ?

P.S.
Node.js does *not* conform. Not at all. Not only it doesn't clamp to 4ms (which 
happens to be a good thing, IMO), but its timers often fire out of order !
-- 
Jorge.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to