setTimeout not executing form submit

J

Jim Ley

Why? Scripts for previous versions would not use the third argument.

yet, it's near impossible to do version detection of javascript...
Are you proposing a sleep() method instead, blocking the UA when called?

Nope, my proposal (which you can see in the www-svg archives) would be
for a delayed dispatchEvent. Although even the current SVG 1.2
proposal I welcome as better than setTimeout, which really is lousy.

Jim.
 
Y

Yann-Erwan Perio

Jim said:
yet, it's near impossible to do version detection of javascript...

Ah, but I assume that detecting JScript wouldn't be too hard, using
conditional compilation and VBArrays...or not?
Nope, my proposal (which you can see in the www-svg archives) would be
for a delayed dispatchEvent. Although even the current SVG 1.2
proposal I welcome as better than setTimeout, which really is lousy.

When reading your first answer I was about to exemplify good uses for
setTimeout (other than addressing browser lack of support for events),
but the more I think to that delayed dispatchEvent, the more valid it
seems to be.

I'm not familiar with SVG yet, scanning the SVG1.2 draft yielded the
SVGRunnable and SVGTimer interfaces, do you really prefer this over
setTimeout?

I mean, it's possible to implement elegant components using setTimeout,
and to me the spec is just proposing an interface to such a component,
which, though IMHO quite correct, remains easily done with javascript
and setTimeout, and seems moreover to be missing the spirit of an
events-based system.

At least setTimeout is much more fun:), and it being easy to use means
more flexibility for the programmer - I don't see any real added value
or innovation in the SVG two interfaces.

As for the "sleep" method, I hate the idea - that'd split the execution
context, so that would deal with javascript, while the timeout only
deals with the host, much neater.


Cheers,
Yep.
 
T

Thomas 'PointedEars' Lahn

Jim said:
Thomas said:
Jim said:
[...] Thomas 'PointedEars' Lahn [...] wrote:
the IE-DOM does support function references from v5.0 on, but not
additional arguments to date (IE 6.0 SP-1) --

There's no way it can since that would break compatibility with every
previous version of _IE_

Why? Scripts for previous versions would not use the third argument.

yet, it's near impossible to do version detection of javascript...

Since JavaScript methods do not have fixed arity I still do not see the
problem. No edition/version of ECMAScript, JavaScript and JScript is 100%
backwards compatible.
Are you proposing a sleep() method instead, blocking the UA when called?

Nope, my proposal (which you can see in the www-svg archives) would be
for a delayed dispatchEvent. [...]

ACK, a standards compliant way of setting a timeout is required.


PointedEars
 
J

Jim Ley

I'm not familiar with SVG yet, scanning the SVG1.2 draft yielded the
SVGRunnable and SVGTimer interfaces, do you really prefer this over
setTimeout?

Possibly not over the setTimeout which takes function reference as
first parameter, and other optional parameters, however due to the
built in weight of setTimeout if it was standardised, everyone would
expect setTimeout("chicken()",100) to work, and I think that's
horrible.

I mean, it's possible to implement elegant components using setTimeout,
and to me the spec is just proposing an interface to such a component,
which, though IMHO quite correct, remains easily done with javascript
and setTimeout, and seems moreover to be missing the spirit of an
events-based system.

Yep, Jan-Klaas Kollhof has implemented it using setTimeout, the
problem with setTimeout is that with the compilation you can't do it
in the compact profile of ECMAScript or in most other langauges, and
DOM is supposed to be language neutral.

Jim.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,996
Messages
2,570,237
Members
46,825
Latest member
VernonQuy6

Latest Threads

Top