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

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.

>     // 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.

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

>         // name attribute of referencing frame/iframe/object, or
> name passed to window.open,
>         // does it make sense to spec this without being html-
> specific or defining open?
>         attribute DOMString name;

Yep, I think it's relevant to spec it, it's not HTML specific in any
particular sense other than currently how it's initialised externally,
it's no less html specific than top/parent and they need specifying.

>         // 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?

> (*) - 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.

Cheers,

Jim.

Received on Tuesday, 14 February 2006 10:55:28 UTC