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

On Feb 14, 2006, at 3:29 AM, Jim Ley wrote:

>
> On 2/14/06, Maciej Stachowiak <mjs@apple.com> wrote:
>> 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:
>
> Ah, sorry, I thought you knew, IE doesn't support this and never has.

No problem dropping it from the spec then (we could add a non- 
normative note on what SafOperFox does).

>> window.setTimeout(timerFunc, 100, "it worked");
>
> In IE that would attempt to execute timerFunc by a script engine
> represented by the string "it worked".

According to Anne it sounds like it calls it with no arguments instead.

> Just checking it appears Batik doesn't support it either.
>
> Given the comments elsewhere on optional parameters in the DOM being
> unfriendly to some implementors I think it's good to just duck it as
> you note.

The comment was from a Mozilla developer, and Mozilla invented the  
extra args feature of setTimeout. So I don't think they can complain  
about problems implementing it. But let's leave it out.

>> 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.
>
> The spec shouldn't IMO forbid much.

Well, an IDL interface with some fixed number of arguments could be  
read as disallowing additional arguments. But we can be extra clear  
about that in this case.

> I think the inherent idea of a function is good, I was just meaning
> deprecate the entire setTimeout in favour of a method without the all
> this legacy baggage that setTimeout has.

I disagree with deprecating it. To deprecate it you would need  
something new. And I would rather avoid inventing new features where  
not absolutely necessary. Also, there's nothing fundamentally wrong  
with the current interface. It is just fine for JavaScript, and could  
be extended in a fairly simple way to also work for Java without  
affecting JS.

>>> 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.
>
> Sure it would, you don't need to specify anything beyond it's a timer
> object, I don't see it as necessary to force this to be a long that is
> all - there's nothing you can do with the returned ID other than pass
> it to clearTimeout why limit it in any way?

Existing code could depend on it being an integer. I don't see much  
reason to change it. It would be more elegant to use an opaque  
interface, but not enough to risk breaking existing code.

Regards,
Maciej

Received on Tuesday, 14 February 2006 12:38:48 UTC