On Oct 3, 2008, at 11:15 AM, Geoffrey Garen wrote:
Hi Chris.
I really like the idea of a Timer object. It would allow you to
separate creation from starting, allows you to pause and add other
API's to the interface. Can the constructor be used to simplify the
creation:
var t = new Timer(0,
On Oct 3, 2008, at 2:11 PM, Robert Sayre wrote:
On Thu, Oct 2, 2008 at 11:43 PM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
A number of WebKit developers (including from the Chrome team and
the Safari
team) have been discussing ideas for a new and improved timer API.
We would
like t
On Thu, Oct 2, 2008 at 11:43 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> A number of WebKit developers (including from the Chrome team and the Safari
> team) have been discussing ideas for a new and improved timer API. We would
> like to serve the following use cases which we feel are not
On Oct 3, 2008, at 10:43 AM, Aaron Boodman wrote:
Hi Maciej,
Thanks for raising this. It's a good addition to the web platform. I'm
definitely +1 to the idea.
2008/10/2 Maciej Stachowiak <[EMAIL PROTECTED]>:
// should be implemented by Window objects
interface WindowTimer {
Timer startTim
On Oct 3, 2008, at 9:33 AM, Travis Leithead wrote:
Mmm. A nice addition to the old timeout properties.
I curious to know more about the use-cases and/or problems
underlying the solution you proposed in #2. Would simply extending
the current timers to be high-resolution help?:
I believe
On Oct 3, 2008, at 11:15 AM, Geoffrey Garen wrote:
Hi Chris.
I really like the idea of a Timer object. It would allow you to
separate creation from starting, allows you to pause and add other
API's to the interface. Can the constructor be used to simplify the
creation:
var t = new Timer(
On Fri, 03 Oct 2008 19:43:34 +0200, Aaron Boodman <[EMAIL PROTECTED]> wrote:
To me, fractional milliseconds does not seem weird. On the webkit-dev
thread, Peter Speck pointed out [1] that the unit of time in web
development is milliseconds. Dates are in milliseconds, setTimeout
takes millisecond
On Oct 3, 2008, at 1:25 PM, Charles McCathieNevile wrote:
On Fri, 03 Oct 2008 05:43:55 +0200, Maciej Stachowiak
<[EMAIL PROTECTED]> wrote:
A number of WebKit developers (including from the Chrome team and
the Safari team) have been discussing ideas for a new and improved
timer API.
[..
On Fri, 03 Oct 2008 05:43:55 +0200, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
A number of WebKit developers (including from the Chrome team and the
Safari team) have been discussing ideas for a new and improved timer API.
[...]
I think we should put this design or something much like it
Hi Chris.
I really like the idea of a Timer object. It would allow you to
separate creation from starting, allows you to pause and add other
API's to the interface. Can the constructor be used to simplify the
creation:
var t = new Timer(0, false, function() { ...});
which would start the
Hi Maciej,
Thanks for raising this. It's a good addition to the web platform. I'm
definitely +1 to the idea.
2008/10/2 Maciej Stachowiak <[EMAIL PROTECTED]>:
> // should be implemented by Window objects
> interface WindowTimer {
>Timer startTimer(in double delayInSeconds, in boolean repeatin
Anne van Kesteren wrote:
On Thu, 02 Oct 2008 01:24:34 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
I think it would be good if we more explicitly could define the two,
with cookies vs. without cookies, security modes for Access-Control.
Right now the spec talks about the with-credentials f
Mmm. A nice addition to the old timeout properties.
I curious to know more about the use-cases and/or problems underlying the
solution you proposed in #2. Would simply extending the current timers to be
high-resolution help?:
>> 2) High-resolution timers to be used to precisely drive animation
On Thu, 02 Oct 2008 01:24:34 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
I think it would be good if we more explicitly could define the two,
with cookies vs. without cookies, security modes for Access-Control.
Right now the spec talks about the with-credentials flag either being
true o
On Oct 3, 2008, at 2:58 AM, Anne van Kesteren wrote:
On Fri, 03 Oct 2008 05:40:26 +0200, Maciej Stachowiak
<[EMAIL PROTECTED]> wrote:
I think [Variadic] should be renamed [Optional]. A function may be
variadic, but a parameter is optional, and this goes on the
parameter.
To me [Option
On Oct 3, 2008, at 4:59 AM, Anne van Kesteren wrote:
On Fri, 03 Oct 2008 05:43:55 +0200, Maciej Stachowiak
<[EMAIL PROTECTED]> wrote:
- Perhaps the argument order should be (handler, delay, repeating)
instead, to be more like setTimeout / setInterval
- Perhaps the "repeating" or even the
Since Jonas didn't e-mail about this I thought I would. Say
http://x.example/x does a request to http://y.example/y.
http://y.example/y redirects to http://x.example/y. If this request were
to use the Access Control specification the algorithm would have a status
return flag set to "same-
On Fri, 03 Oct 2008 05:43:55 +0200, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
- Perhaps the argument order should be (handler, delay, repeating)
instead, to be more like setTimeout / setInterval
- Perhaps the "repeating" or even the "delayInSeconds" arguments should
be optional, defaul
On Fri, 03 Oct 2008 05:40:26 +0200, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
I think [Variadic] should be renamed [Optional]. A function may be
variadic, but a parameter is optional, and this goes on the parameter.
To me [Optional] does not really convey zero or more arguments very well
On Oct 3, 2008, at 1:40 AM, Geoffrey Garen wrote:
Pros:
* Fits the object-oriented programming model of "new Image", "new
XMLHttpRequest", etc.
* Enables use of object-oriented features like instanceof,
the .constructor property, and prototype-based extensions to timer
objects.
* Di
Pros:
* Fits the object-oriented programming model of "new Image", "new
XMLHttpRequest", etc.
* Enables use of object-oriented features like instanceof,
the .constructor property, and prototype-based extensions to timer
objects.
* Distinguishes itself better from the old setTimeout /
On Oct 3, 2008, at 12:03 AM, Geoffrey Garen wrote:
// should be implemented by Window objects
interface WindowTimer {
Timer startTimer(in double delayInSeconds, in boolean repeating,
in TimerHandler handler);
}
How about a "Timer" constructor function instead?
Pros:
* Fits the object-o
// should be implemented by Window objects
interface WindowTimer {
Timer startTimer(in double delayInSeconds, in boolean repeating,
in TimerHandler handler);
}
How about a "Timer" constructor function instead?
Pros:
* Fits the object-oriented programming model of "new Image", "new
XMLHt
23 matches
Mail list logo
