Re: Window object, very rough cut of proposed content for first version of spec

On Feb 14, 2006, at 2:53 AM, Jim Ley wrote:

>
> On 2/14/06, Maciej Stachowiak <mjs@apple.com> wrote:
>> I propose one of the following for the title:
>>
>> DOM Global Object (Level 3? or 1.0?)
>> DOM Window Object (Level 3? or 1.0?)
>> DOM Level 3 Views (especially if we incorporate AbstractView and
>> DocumentView interfaces into this spec instead of just referencing
>> views)
>
> Either of the first two, preferably the 2nd, the 3rd is just a
> confusing name to the majority of the population.

Noted.

>>     // for ECMAScript there is a special case for this type, it can
>> be either a string or a function.
>>     // In the string case, the string is eval'd in global scope when
>> the timer fires.
>>     // in the function case JS allows extra arguments after the
>> milliseconds argument; the function
>
> This is extremely tough to spec I think.  I think the "extra
> arguments" are a bad idea, it's not compatible with legacy UA's, and
> in JS the same can be acheived with native ES methods to pass a
> function with the variables you want in scope.  So I'd say no
> arguments in this standardised version to avoid any issues with
> suddenly naming legacy UA's non-compliant when it's not necessary.

Not sure what you mean by legacy UAs. It works in Safari, Firefox,  
and Opera. I haven't tested Internet Explorer yet. Here's my test case:

<script>
function timerFunc(s)
{
    alert(s);
}
window.setTimeout(timerFunc, 100, "it worked");
</script>

I'm happy to drop this feature if IE can't do it, so long as the spec  
doesn't forbid supporting extra arguments in this way. I can test  
tomorrow if no one else does by then.

> There's also the issue of string/function.  I think it would be nice
> to deprecate it immediately in favour of a better approach.

I don't think the use of functions needs to be deprecated. If they  
are good enough to use in addEventListener, then surely they are good  
enough for timers. I think strings should be supported as an  
ECMAScript binding only feature. I would consider writing the spec to  
also accept an EventListener that gets some kind of TimerEvent, the  
function and string versions could be explained in terms of that.

Also, strictly speaking the extra args feature for functions is  
redundant because ECMAScript has anonymous functions. Instead of:

setTimeout(func, 100, "arg1", 3133.7);

you could write:

setTimeout(function() { func("arg1", 3133.7); }, 100);

The extra args are marginally more convenient, I suppose.

IE also lets you specify a language for the string version (as in the  
whatwg draft), but the allowed values are only JScript, VBScript and  
JavaScript, so I am not sure this would be applicable to any other UA.

>>         // should timers allow more than long, maybe a floating
>> point type? don't think anyone's timers have more precision
>>         // one-shot timer
>>         long setTimeout(in TimerListener listener, in long
>> milliseconds);
>>         void clearTimeout(in long timerID);
>
> Is it really right to specify this as a long?  wouldn't a
> timerReference be better?

Timer IDs are integer values in existing UAs. I agree a Timer object  
would be more elegant but it would not be compatible.

>> (*) - I think this is unneeded, because there's no need to enable one
>> language to set a timer that will eval code in another language. I
>> think the string parameter versions of these should instead be
>> defined as an ECMAScript binding feature and not in the IDL.
>
> It's actually surprisingly common for me to call a script in a
> different language in a multi-script environment, I generally use
> execScript rather than setTimeout with the language, but the actual
> use case is common.  As I say above it would be better to just duck
> the issue and leave setTimeout standardised around function
> (function/string, delay) without any arguments.

Cross-language script execution would be better specified as a  
separate feature instead of overloaded onto timers IMO.

Regards,
Maciej

Received on Tuesday, 14 February 2006 11:21:37 UTC