setTimeout() & ECMA

Discussion in 'Javascript' started by Andre, Mar 11, 2006.

  1. Andre

    Andre Guest

    Hi,

    Does anyone know whether the ECMA, or an other standard document,
    specifies a maximum for the value that can be pass to the setTimeOut()
    function in Javascript?

    Andre
     
    Andre, Mar 11, 2006
    #1
    1. Advertising

  2. Andre

    Jim Ley Guest

    On 11 Mar 2006 12:38:13 -0800, "Andre" <>
    wrote:

    >Does anyone know whether the ECMA, or an other standard document,
    >specifies a maximum for the value that can be pass to the setTimeOut()
    >function in Javascript?


    setTimeout is not standardised anywhere.

    Jim.
     
    Jim Ley, Mar 11, 2006
    #2
    1. Advertising

  3. Andre

    Randy Webb Guest

    Andre said the following on 3/11/2006 3:38 PM:
    > Hi,
    >
    > Does anyone know whether the ECMA, or an other standard document,
    > specifies a maximum for the value that can be pass to the setTimeOut()
    > function in Javascript?


    It would surprise me if there was one as it's irrelevant to the language
    itself. But, if it does exist, then it's irrelevant anyway because I can
    write a timeout to last as long as I want no matter what any spec may say.

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Mar 11, 2006
    #3
  4. >> Does anyone know whether the ECMA, or an other standard document,
    >> specifies a maximum for the value that can be pass to the setTimeOut()
    >> function in Javascript?


    > It would surprise me if there was one as it's irrelevant to the language
    > itself. But, if it does exist, then it's irrelevant anyway because I can
    > write a timeout to last as long as I want no matter what any spec may say.


    It may surprise you that setTimeout is not covered by an ECMA standard, nor by a
    W3C standard. There are some holes in the web standards. This is one of them.
    I'm looking to the WHAT Working Group to fix this. See
    http://www.whatwg.org/specs/web-apps/current-work/

    There doesn't seem to be a problem in setting the timeout value to something
    that is vastly greater than the MTBF of the browser. All that means is that the
    timeout may never fire.

    http://javascript.crockford.com/
     
    Douglas Crockford, Mar 11, 2006
    #4
  5. Andre

    Randy Webb Guest

    Douglas Crockford said the following on 3/11/2006 5:56 PM:
    >>> Does anyone know whether the ECMA, or an other standard document,
    >>> specifies a maximum for the value that can be pass to the setTimeOut()
    >>> function in Javascript?

    >
    >> It would surprise me if there was one as it's irrelevant to the
    >> language itself. But, if it does exist, then it's irrelevant anyway
    >> because I can write a timeout to last as long as I want no matter what
    >> any spec may say.

    >
    > It may surprise you that setTimeout is not covered by an ECMA standard,
    > nor by a W3C standard.


    It does but it doesn't.

    > There are some holes in the web standards. This is one of them. I'm
    > looking to the WHAT Working Group to fix this. See
    > http://www.whatwg.org/specs/web-apps/current-work/



    Is there some underlying problem with setTimeout that it needs to be
    standardized for any reason other than so it is standardized?


    > There doesn't seem to be a problem in setting the timeout value to
    > something that is vastly greater than the MTBF of the browser. All that
    > means is that the timeout may never fire.


    True. But even if there were a limit to a single call to setTimeout you
    can exceed that limit by using multiple or recursive setTimeouts to get
    the desired result. So any attempt to set a limit on the timer of
    setTimeout would lead to more problems than it ever tried to solve and
    would lead to code that looked something like this:

    var timer1 = 0;
    var loops = 30;

    function SetTimeOut(){
    if (timer1 == loops)
    {
    realFunctionYouWantToCall();
    }
    else{
    timer1++;
    window.setTimeout(SetTimeOut,maxValue);
    }
    }
    window.setTimeout(SetTimeOut,maxValue);

    Where maxValue would be the maximum value you could pass to setTimeout.

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Mar 11, 2006
    #5
  6. Andre

    Jim Ley Guest

    On Sat, 11 Mar 2006 18:55:20 -0500, Randy Webb
    <> wrote:

    >Is there some underlying problem with setTimeout that it needs to be
    >standardized for any reason other than so it is standardized?


    None at all, these de facto standards don't need to be standardised,
    in fact standardising them can be very difficult. What is useful is
    documenting what UAs do in a single place.

    The WHAT WG Individual here is doing a valuable thing, unfortunately
    writing it up as a spec is less helpful.

    In any case, the work on the window object is also being documented by
    W3 WEB API group <URL: http://www.w3.org/2006/webapi/ > including
    setTimeout - You can even join in the discussion, e.g. <URL:
    http://www.w3.org/mid/3.org >

    (and is likely to leave the Web Apps in the WHAT...)

    Jim.
     
    Jim Ley, Mar 12, 2006
    #6
  7. Andre wrote:

    > Does anyone know whether the ECMA, or an other standard document,
    > specifies a maximum for the value that can be pass to the setTimeOut()
    > function in Javascript?


    There is no setTimeOut() function, and there is no Javascript.
    That was easy :)

    Seriously, the language we are talking about in this case is either
    (Netscape) JavaScript, or (Microsoft) JScript, or an implementation
    of one or both of them. With the exception of JavaScript 1.0, both
    languages are indeed conforming ECMAScript implementations.

    But as Jim already said, setTimeout(), as it is spelled properly,
    is not defined by any specification as yet. It is a method of the
    host object that can be referred to by `window' (and often, if not
    always, a method of the Global Object in HTML UAs), which was never
    really a part of any programming language, instead it is a feature
    of the AOM/DOM of an HTML user agent. (Although it is included in
    the JavaScript References from versions 1.0 to 1.3, thereby referring
    to the Netscape Navigator AOM/DOM.)

    Probably you mean the value of the second argument of that method,
    specifying the timeout length in milliseconds. So far there is no
    reference material that says anything about a maximum value for it
    explicitly:

    JavaScript 1.3 Reference
    <URL:http://research.nihonsoft.org/javascript/ClientReferenceJS13/window.html#1203758>

    Gecko DOM Reference
    <URL:http://developer.mozilla.org/en/docs/DOM:window.setTimeout>

    MSDN Library: HTML and DHTML Reference
    <URL:http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/settimeout.asp>

    Opera DOM
    <URL:http://www.opera.com/docs/specs/opera6/js/index.dml>

    KHTML (Konqueror, Safari)
    <http://developer.kde.org/documentation/library/3.1-api/khtml/html/classKJS_1_1ScheduledAction.html>
    ....
    <http://developer.kde.org/documentation/library/3.4-api/khtml/html/classKJS_1_1ScheduledAction.html>

    But for some UAs, you can read the Source, Luke:

    <URL:http://lxr.mozilla.org/mozilla1.8.0/source/dom/src/base/nsGlobalWindow.cpp#5971>

    The lines

    | #define DOM_MAX_TIMEOUT_VALUE PR_BIT(8 * sizeof(PRIntervalTime) - 1)

    and

    ,-<URL:http://lxr.mozilla.org/mozilla1.8.0/source/nsprpub/pr/include/prtypes.h#240>
    | #define PR_BIT(n) ((PRUint32)1 << (n))

    ,-<URL:http://lxr.mozilla.org/mozilla1.8.0/source/nsprpub/pr/include/prinrval.h#61>
    | typedef PRUint32 PRIntervalTime;

    ,-<URL:http://lxr.mozilla.org/mozilla1.8.0/source/nsprpub/pr/include/prtypes.h#330>
    | typedef unsigned int PRUint32;

    suggest (if I understand it correctly) that the maximum timeout length in a
    Gecko-based UAs compiled for and running on a 32-bit machine is (following
    the preprocessor steps)

    PR_BIT(8 * sizeof(PRIntervalTime) - 1)
    == ((unsigned int)1 << (8 * sizeof(PRUint32) - 1))
    == ((unsigned int)1 << (8 * sizeof(unsigned int) - 1))
    == ((unsigned int)1 << (8 * 4 - 1))
    == ((unsigned int)1 << 31)
    == 2147483648

    milliseconds, which equals 24 standard days, 20 hours, 31 minutes, and
    23.648 seconds. According to nsGlobalWindow.cpp, lines 6051 to 6055,
    greater values will be normalized to that value.

    What is most interesting is that this source code also makes it clear that
    Gecko 1.8.0-based UAs (such as Firefox 1.5.0.1) will not handle timeouts or
    intervals shorter than 10 milliseconds (nsGlobalWindow.cpp, lines 6044 to
    6049, and 191 and 192). So if you provide a smaller value, the actual
    timeout/interval length will be 10 milliseconds.

    And for KHTML-based UAs:

    <URL:http://developer.kde.org/documentation/library/3.4-api/khtml/html/kjs__window_8h-source.html#l00177>

    Since the value must be parsed by an ECMAScript implementation, the general
    theoretical maximum value is max(IEEE754_DOUBLE), 1.798E308, which equals
    about 5.7E297 years. However, it is probable that other implementations
    also use an Integer type here, which would restrict the maximum value for
    window.setTimeout() to the maximum value an extended integer register can
    hold on the particular platform, assuming the use of a generic data type
    in the UA's source code, such as `unsigned int' in C++.

    If you mean the length of the string that can be used as the first argument
    instead, there is nothing in the reference material about that either.
    String literals (and C++ strings, which are in fact pointers to character
    data) can be of arbitrary length; it is just a matter of available memory.


    HTH

    PointedEars
     
    Thomas 'PointedEars' Lahn, Mar 12, 2006
    #7
  8. Andre

    Randy Webb Guest

    Jim Ley said the following on 3/11/2006 7:17 PM:
    > On Sat, 11 Mar 2006 18:55:20 -0500, Randy Webb
    > <> wrote:
    >
    >> Is there some underlying problem with setTimeout that it needs to be
    >> standardized for any reason other than so it is standardized?

    >
    > None at all, these de facto standards don't need to be standardised,
    > in fact standardising them can be very difficult. What is useful is
    > documenting what UAs do in a single place.


    Agreed.

    > The WHAT WG Individual here is doing a valuable thing, unfortunately
    > writing it up as a spec is less helpful.


    Understood. As long as there is no limit on the time, as I showed, it is
    easily circumvented making it moot to add it and only leads to
    complicating code.

    > In any case, the work on the window object is also being documented by
    > W3 WEB API group <URL: http://www.w3.org/2006/webapi/ > including
    > setTimeout - You can even join in the discussion, e.g. <URL:
    > http://www.w3.org/mid/3.org >
    >
    > (and is likely to leave the Web Apps in the WHAT...)


    I might read up on it :) Looks to be interesting.

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Mar 12, 2006
    #8
  9. JRS: In article <>,
    dated Sat, 11 Mar 2006 12:38:13 remote, seen in
    news:comp.lang.javascript, Andre <> posted :

    >Does anyone know whether the ECMA, or an other standard document,
    >specifies a maximum for the value that can be pass to the setTimeOut()
    >function in Javascript?


    The value is a Number of milliseconds, and its limit is therefore the
    maximum IEEE Double, a bit over 1.7E308, meaning about 5.3E297 years.

    It's probable that the timeout operation will be implemented by the
    operating system, and that the OS will impose a lower usable limit.
    That's likely to be 2^N-1 ms, where N = 31 or 32. In Windows, 32,
    allowing 49 days 17:02:47.295.

    The MTBF of the browser should exceed 50 days; that of the OS might not.

    Untested.

    --
    © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
    <URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
    <URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
    <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
     
    Dr John Stockton, Mar 12, 2006
    #9
  10. >>>> Does anyone know whether the ECMA, or an other standard document,
    >>>> specifies a maximum for the value that can be pass to the setTimeOut()
    >>>> function in Javascript?


    >> There are some holes in the web standards. This is one of them. I'm
    >> looking to the WHAT Working Group to fix this. See
    >> http://www.whatwg.org/specs/web-apps/current-work/


    > Is there some underlying problem with setTimeout that it needs to be
    > standardized for any reason other than so it is standardized?


    The original question was what does the standard say? When you look to the
    standard to answer questions, and the standard does not exist, that could be
    viewed as a problem.

    The lack of a standard should also be a concern to people who are dedicated to
    standards based development. There are some fierce web developers who refuse to
    touch anything that is not strictly standards compliant. How can a browser be
    fully standards compliant if there do not exist standards for it to conform to?

    Defacto standards and proprietary standards are not sufficient, I think.

    http://javascript.crockford.com/
     
    Douglas Crockford, Mar 13, 2006
    #10
  11. Andre

    Randy Webb Guest

    Douglas Crockford said the following on 3/12/2006 8:43 PM:
    >>>>> Does anyone know whether the ECMA, or an other standard document,
    >>>>> specifies a maximum for the value that can be pass to the setTimeOut()
    >>>>> function in Javascript?

    >
    >>> There are some holes in the web standards. This is one of them. I'm
    >>> looking to the WHAT Working Group to fix this. See
    >>> http://www.whatwg.org/specs/web-apps/current-work/

    >
    >> Is there some underlying problem with setTimeout that it needs to be
    >> standardized for any reason other than so it is standardized?

    >
    > The original question was what does the standard say? When you look to
    > the standard to answer questions, and the standard does not exist, that
    > could be viewed as a problem.


    Makes sense to me :)

    > The lack of a standard should also be a concern to people who are
    > dedicated to standards based development. There are some fierce web
    > developers who refuse to touch anything that is not strictly standards
    > compliant. How can a browser be fully standards compliant if there do
    > not exist standards for it to conform to?


    Language extensions, which are allowed by the standards.

    But, is there also a movement to standardize innerHTML? It would, to me,
    fall into the same category.

    > Defacto standards and proprietary standards are not sufficient, I think.


    That is why I was asking about the reason for standardizing it.

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Mar 13, 2006
    #11
  12. Andre

    VK Guest

    Randy Webb wrote:
    > Jim Ley said the following on 3/11/2006 7:17 PM:
    > > On Sat, 11 Mar 2006 18:55:20 -0500, Randy Webb
    > > <> wrote:
    > >
    > >> Is there some underlying problem with setTimeout that it needs to be
    > >> standardized for any reason other than so it is standardized?

    > >
    > > None at all, these de facto standards don't need to be standardised,
    > > in fact standardising them can be very difficult. What is useful is
    > > documenting what UAs do in a single place.

    >
    > Agreed.


    Disagreed.
    See
    <http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/f127aa709e894c0c/0c0d836d49b2d779>

    There is a huge discrepancy on handling timed execution calls (let's
    spit over the shoulder and call it "threads" any further, keeping
    "pseudo-" preffix in mind).

    The way Firefox handles threads on modal dialog call (alert, confirm,
    prompt) is not to say non-standard - as we don't have a written
    standard - but highly innovative in the relation to the tradition.
    Actually in order to accomplish that they also changed modal dialogs to
    "half-modal" dialogs: dialogs from different threads allowed to popup
    one behind other, so you can have N dialogs on the page at once -
    though the page access is still locked until the last dialog is
    dismissed. Thinking of any GIU I had to deal with I cannot come up with
    any equivalent of that - though it is possibly of lack of OS
    experience.

    In any case it should be clearly documented - or changed to the
    conventional way.
     
    VK, Mar 13, 2006
    #12
  13. Andre

    Randy Webb Guest

    VK said the following on 3/13/2006 3:43 AM:
    > Randy Webb wrote:
    >> Jim Ley said the following on 3/11/2006 7:17 PM:
    >>> On Sat, 11 Mar 2006 18:55:20 -0500, Randy Webb
    >>> <> wrote:
    >>>
    >>>> Is there some underlying problem with setTimeout that it needs to be
    >>>> standardized for any reason other than so it is standardized?
    >>> None at all, these de facto standards don't need to be standardised,
    >>> in fact standardising them can be very difficult. What is useful is
    >>> documenting what UAs do in a single place.

    >> Agreed.

    >
    > Disagreed.
    > See
    > <http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/f127aa709e894c0c/0c0d836d49b2d779>
    >
    > There is a huge discrepancy on handling timed execution calls (let's
    > spit over the shoulder and call it "threads" any further, keeping
    > "pseudo-" preffix in mind).
    >
    > The way Firefox handles threads on modal dialog call (alert, confirm,
    > prompt) is not to say non-standard - as we don't have a written
    > standard - but highly innovative in the relation to the tradition.
    > Actually in order to accomplish that they also changed modal dialogs to
    > "half-modal" dialogs: dialogs from different threads allowed to popup
    > one behind other, so you can have N dialogs on the page at once -
    > though the page access is still locked until the last dialog is
    > dismissed. Thinking of any GIU I had to deal with I cannot come up with
    > any equivalent of that - though it is possibly of lack of OS
    > experience.
    >
    > In any case it should be clearly documented - or changed to the
    > conventional way.
    >


    Let me quote it to you VK, ok?

    <quote cite="Jim Ley">
    What is useful is documenting what UAs do in a single place.
    </quote>
    <quote cite="Randy Webb">
    Agreed
    </quote>

    Which is precisely what you just said.

    If some organization came out tomorrow and attempted to standardize
    setTimeout then I would definitely read it, but it wouldn't change my
    thoughts about it. Standards are great, but not the end all of end alls.
    I worry more about what browsers do than what some spec says they
    *should* do. And a single place that documented how different browsers
    handle setTimeout would be a lot more valuable to me than any standard
    on it ever will be.

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Mar 13, 2006
    #13
  14. Andre

    Jim Ley Guest

    On Mon, 13 Mar 2006 01:43:50 GMT, Douglas Crockford
    <> wrote:
    >Defacto standards and proprietary standards are not sufficient, I think.


    And then you pointed to the WHAT-WG which is a proprietary standard
    from a Google employee? [*] So I'm not sure what your point is.

    Standards take an immense amount of work to produce - notes on what
    people have done take much less, Hixie alone can do the later in a
    couple of man years. Given things which are extremely interopable
    there's little point in investing the cost of standardising them, when
    there are a lot more important things to standardise.

    If you have the time Douglas - join the Web API's Working Group, you
    work for a member company - the more resources there are, the more
    standards that can be produced.

    Jim.

    [*] With a debateable copyright notice pointing to other vendors.
     
    Jim Ley, Mar 13, 2006
    #14
  15. Andre

    Randy Webb Guest

    Jim Ley said the following on 3/13/2006 5:31 AM:
    > On Mon, 13 Mar 2006 01:43:50 GMT, Douglas Crockford
    > <> wrote:
    >> Defacto standards and proprietary standards are not sufficient, I think.

    >
    > And then you pointed to the WHAT-WG which is a proprietary standard
    > from a Google employee? [*] So I'm not sure what your point is.
    >
    > Standards take an immense amount of work to produce - notes on what
    > people have done take much less, Hixie alone can do the later in a
    > couple of man years.


    I don't know if having a Jim Ley assigned nickname is a good thing or
    not as I don't know of anyone else who has one :) Hmmm

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Mar 13, 2006
    #15
  16. Andre

    Jim Ley Guest

    On Mon, 13 Mar 2006 18:40:24 -0500, Randy Webb
    <> wrote:

    >> Standards take an immense amount of work to produce - notes on what
    >> people have done take much less, Hixie alone can do the later in a
    >> couple of man years.

    >
    >I don't know if having a Jim Ley assigned nickname is a good thing or
    >not as I don't know of anyone else who has one :) Hmmm


    Hixie is not a Jim Ley assigned nickname, it's Ian's IRC nick, his
    website address etc. I've even heard people use it to his face.

    Jim.
     
    Jim Ley, Mar 14, 2006
    #16
  17. Andre

    Randy Webb Guest

    Jim Ley said the following on 3/13/2006 7:50 PM:
    > On Mon, 13 Mar 2006 18:40:24 -0500, Randy Webb
    > <> wrote:
    >
    >>> Standards take an immense amount of work to produce - notes on what
    >>> people have done take much less, Hixie alone can do the later in a
    >>> couple of man years.

    >> I don't know if having a Jim Ley assigned nickname is a good thing or
    >> not as I don't know of anyone else who has one :) Hmmm

    >
    > Hixie is not a Jim Ley assigned nickname, it's Ian's IRC nick, his
    > website address etc. I've even heard people use it to his face.


    Can I go hide my face now?

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Mar 14, 2006
    #17
  18. Andre

    VK Guest

    Randy Webb wrote:

    > Let me quote it to you VK, ok?


    oky-toky, you may try :)

    > <quote cite="Jim Ley">
    > What is useful is documenting what UAs do in a single place.
    > </quote>
    > <quote cite="Randy Webb">
    > Agreed
    > </quote>
    >
    > Which is precisely what you just said.


    I said that Firefox' setTimeout behavior is <q>highly innovative</q> -
    and I should maybe say "overly innovative". And the options I asked was
    either to provide a written commitment from Mozilla that this will be
    forever until Firefox exists - or drop it for the standard behavior
    before it's too late (unless it's already too late).
    Here I'm taking "standard" not like something "described and sealed (by
    W3C)" but in the most common primary sense: "something considered by an
    authority or *by general consent* as a basis of comparison".
    "by general consent" part is always conveniently ommited by W3C members
    when they raise their eyes up and start talking about Standards. :)
    <offtopic>
    In the reality the "general consent" has much greater value than any
    amout of signed papers. Until it's not clearly understood by W3C and Co
    they will continue make nasty oopsies like say XHTML.
    </offtopic>

    setTimeout is not documented, nor alert, confirm or prompt. But there
    is a public expectation of them and their behavior. I mean how many
    chances do you give to a browser not having window.setTimeout or
    window.alert ? I give Number.NEGATIVE_INFINITY - despite no one browser
    is obligated by written standards to have it.

    And I really don't like that for a decade now "window" is being bounced
    from Pontius to Kijafa and back: ECMA doesn't take it because it's a
    host object, W3C doesn't take because it's not a part of HTML. So such
    vital and throughout implemented object is kind of out of any existing
    schema.

    > If some organization came out tomorrow and attempted to standardize
    > setTimeout then I would definitely read it, but it wouldn't change my
    > thoughts about it. Standards are great, but not the end all of end alls.
    > I worry more about what browsers do than what some spec says they
    > *should* do. And a single place that documented how different browsers
    > handle setTimeout would be a lot more valuable to me than any standard
    > on it ever will be.


    It really depends on how big a particular discrepancy is. If 20px plus
    minus and so then it's semi OK - we have to live with this srap since
    the beginning of time. :-(

    If all browsers but one halt all threads on alert, but the one doesn't
    - it's a Problem. Same if 90% of clients get real nodes count but in up
    to 10% you have to expect phantom nodes counted so all build-in XML
    methods are useless and you have to write wrappers atop of each - this
    is a Problem.
     
    VK, Mar 14, 2006
    #18
  19. Andre

    Jim Ley Guest

    On 14 Mar 2006 03:54:07 -0800, "VK" <> wrote:

    > ECMA doesn't take it because it's a
    >host object, W3C doesn't take because it's not a part of HTML. So such
    >vital and throughout implemented object is kind of out of any existing
    >schema.


    The W3 Web Api's working are writing up the standard as we speak,
    Maciej has already posted one public editors draft, don't complain, go
    join the mailing list, they are doing it all very much in public - (I
    even managed to wonder into their face 2 face without any problems
    other than the snow...)

    http://www.w3.org/2006/webapi/

    and the email list

    http://lists.w3.org/Archives/Public/public-webapi/

    and IRC channel

    irc://irc.freenode.net:6667/#webapi

    Jim.
     
    Jim Ley, Mar 14, 2006
    #19
  20. Andre

    VK Guest

    Thomas 'PointedEars' Lahn wrote:
    > What is most interesting is that this source code also makes it clear that
    > Gecko 1.8.0-based UAs (such as Firefox 1.5.0.1) will not handle timeouts or
    > intervals shorter than 10 milliseconds (nsGlobalWindow.cpp, lines 6044 to
    > 6049, and 191 and 192). So if you provide a smaller value, the actual
    > timeout/interval length will be 10 milliseconds.


    Excellent research. My Santas had to run many miles since December
    before things started to go right :)

    <http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/31734a3b21535ff5/eb99e9ae13739a95>
     
    VK, Mar 14, 2006
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. PJ
    Replies:
    0
    Views:
    405
  2. Michael Rasmussen

    ECMA-372 is stepping in on C++

    Michael Rasmussen, Jan 20, 2006, in forum: C++
    Replies:
    12
    Views:
    639
    Chris Hills
    Jan 22, 2006
  3. pondus
    Replies:
    2
    Views:
    87
    Giles Bowkett
    Oct 31, 2006
  4. John Bentley
    Replies:
    14
    Views:
    373
    Jim Ley
    Feb 5, 2004
  5. Next Generation Technologies Inc.

    Making a MS jscript ECMA/DOM compliant

    Next Generation Technologies Inc., Feb 7, 2005, in forum: Javascript
    Replies:
    3
    Views:
    99
    NGT Inc.
    Feb 19, 2005
Loading...

Share This Page