- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 27 Jan 2007 15:47:41 -0800
- To: Jim Ley <jim@jibbering.com>
- Cc: Charles McCathieNevile <chaals@opera.com>, Web API public <public-webapi@w3.org>, SVG working group <w3c-svg-wg@w3.org>, Anne van Kesteren <annevk@opera.com>
On Jan 27, 2007, at 2:57 PM, Jim Ley wrote: > > "Anne van Kesteren" <annevk@opera.com> >> On Sat, 27 Jan 2007 12:59:00 -0500, Charles McCathieNevile >> <chaals@opera.com> wrote: >>> This is because we are allegedly going to get around to it, if I >>> recall >>> correctly. If you're keen, I would suggest you further track >>> exactly where that got up to. It being Saturday morning, I don't >>> recall which spec >>> it falls in... >> >> Window will specify it for ECMAScript. Most other languages >> already have a library for doing this. > > Has there been any attempt to punt timers to the ECMA 2.0 people, > as it really is not a WEB API, and it's only being done as a band- > aid to the ES limited people. It might be nice to then just write > up setTimeout on a if you're going to do it, do it like this. > Rather than make the effort to design a suitable WEB-API for timers? Timers in the Window spec are needed not just to paper over ECMAScript limitations, but specifically to define a timer that plays well with the user agent's event/paint loop. In particular, for safety and interoperability, you need to ensure that timers fire at a time when the DOM is in a consistent state, and you have to describe how they interact with things like location changes, style updates, etc. So even languages like Java need a defined timer API. Java has its own timers, but because each runs on a separate thread, they can give no guarantees about running at an appropriate time. In fact they can't even give very good guarantees about firing order. Regards, Maciej
Received on Saturday, 27 January 2007 23:48:40 UTC