Loading ...
Sorry, an error occurred while loading the content.

option.browser

Expand Messages
  • Douglas Crockford
    The Assume a browser no longer supplies window and self . Having multiple representations of global variable access is a source of confusion. When feature
    Message 1 of 8 , May 2, 2009
    View Source
    • 0 Attachment
      The "Assume a browser" no longer supplies 'window' and 'self'. Having multiple representations of global variable access is a source of confusion.

      When feature testing, it is recommended that you use

      if (typeof console === 'object') {

      instead of

      if (window.console) {

      Otherwise, use of window is unnecessary. Use document instead of window.document.

      If you really must have access to window, declare it with

      /*global window */

      ----

      I added table-cell to the set of CSS display values.
    • pauanyu
      ... I am curious, why is: if (typeof foo === undefined ) { better than: if (!foo) { ?
      Message 2 of 8 , May 4, 2009
      View Source
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
        >
        > When feature testing, it is recommended that you use
        >
        > if (typeof console === 'object') {
        >
        > instead of
        >
        > if (window.console) {
        >

        I am curious, why is:
        if (typeof foo === 'undefined') {

        better than:
        if (!foo) {

        ?
      • crlender
        ... In your example, if foo is not declared, it will result in a ReferenceError being thrown. This won t happen if you test with the typeof operator. I think
        Message 3 of 8 , May 4, 2009
        View Source
        • 0 Attachment
          --- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:
          > I am curious, why is:
          > if (typeof foo === 'undefined') {
          >
          > better than:
          > if (!foo) {

          In your example, if foo is not declared, it will result in a
          ReferenceError being thrown. This won't happen if you test with the
          typeof operator. I think DC's point was about avoiding the reference
          to 'window' when testing for a global variable, since 'window' is no
          longer part of option.browser.

          In addition to that, '!foo' converts a value to boolean, and some
          host objects (especially in IE) are known to throw exceptions if
          you try that. typeof is always safe*.

          - Conrad


          * Except, I think, in one weird Safari 2 bug when items of a
          NodeList are checked, but I'd have to look that up.
        • pauanyu
          ... I see; thank you. Another question, why use: if (typeof console === object ) { Instead of: if (console instanceof Object) { ? As far as I know, if
          Message 4 of 8 , May 5, 2009
          View Source
          • 0 Attachment
            --- In jslint_com@yahoogroups.com, "crlender" <crlender@...> wrote:
            >
            > In your example, if foo is not declared, it will result in a
            > ReferenceError being thrown. This won't happen if you test with the
            > typeof operator. I think DC's point was about avoiding the reference
            > to 'window' when testing for a global variable, since 'window' is no
            > longer part of option.browser.
            >
            > In addition to that, '!foo' converts a value to boolean, and some
            > host objects (especially in IE) are known to throw exceptions if
            > you try that. typeof is always safe*.
            >
            > - Conrad
            >
            >
            > * Except, I think, in one weird Safari 2 bug when items of a
            > NodeList are checked, but I'd have to look that up.
            >

            I see; thank you. Another question, why use:
            if (typeof console === 'object') {

            Instead of:
            if (console instanceof Object) {

            ?

            As far as I know, if "console" is null, typeof will return 'object', which would break the first code.

            P.S. I know what the point of Douglas' post is, but he brought up the idea of using typeof, and I was curious why he recommended it, rather than an alternative.
          • Marcel Duran
            ... typeof will always return a string result, hence you have a guarantee you ll get something to test against, on the other hand when testing with: if
            Message 5 of 8 , May 8, 2009
            View Source
            • 0 Attachment
              On Tue, May 5, 2009 at 9:47 AM, pauanyu <pcxunlimited@...> wrote:

              > I see; thank you. Another question, why use:
              > if (typeof console === 'object') {
              >
              > Instead of:
              > if (console instanceof Object) {
              >
              > ?
              >
              > As far as I know, if "console" is null, typeof will return 'object', which
              > would break the first code.
              >
              >



              typeof will always return a string result, hence you have a guarantee you'll
              get something to test against, on the other hand when testing with:

              if (console instanceof Object) {

              if console isn't declared you'll get a ReferenceError when trying to use
              instanceof. You likely won't have problems on firefox w/ firebug which has
              the console declared.


              --
              Marcel Duran


              [Non-text portions of this message have been removed]
            • douglascrockford
              The browser predefinition list has gotten a lot shorter: /*global clearInterval: false, clearTimeout: false, document: false, event: false, frames: false,
              Message 6 of 8 , Feb 11, 2011
              View Source
              • 0 Attachment
                The browser predefinition list has gotten a lot shorter:

                /*global clearInterval: false, clearTimeout: false,
                document: false, event: false, frames: false,
                history: false, Image: false, location: false,
                name: false, navigator: false, Option: false,
                parent: false, screen: false, setInterval: false,
                setTimeout: false, XMLHttpRequest: false */

                The window.* methods and related properties have been removed.
                It is generally a bad idea to be poking at the window object,
                but if you must, do it explicitly. Write

                window.addEventListener(...)

                and not

                addEventListener(...)

                because the implicit form fails in strict mode. When a function is called as a function, this will be bound to undefined. In sloppy mode, this was bound to the global object, which was a bad idea, which enabled the implicit form, which was also a bad idea.
              • Rob Richardson
                I see setTimeout (and cousins) are still in the browser defined list, but would you recomend the same rule of thumb be true for these? E.g. would you
                Message 7 of 8 , Feb 11, 2011
                View Source
                • 0 Attachment
                  I see setTimeout (and cousins) are still in the browser defined list, but
                  would you recomend the same rule of thumb be true for these? E.g. would you
                  recommend "window.setTimeout( func...." rather than "setTimeout( func...."?

                  Rob


                  -----Original Message-----
                  From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
                  Behalf Of douglascrockford
                  Sent: Friday, February 11, 2011 8:17 AM
                  To: jslint_com@yahoogroups.com
                  Subject: [jslint] option.browser

                  The browser predefinition list has gotten a lot shorter:

                  /*global clearInterval: false, clearTimeout: false,
                  document: false, event: false, frames: false,
                  history: false, Image: false, location: false,
                  name: false, navigator: false, Option: false,
                  parent: false, screen: false, setInterval: false,
                  setTimeout: false, XMLHttpRequest: false */

                  The window.* methods and related properties have been removed.
                  It is generally a bad idea to be poking at the window object,
                  but if you must, do it explicitly. Write

                  window.addEventListener(...)

                  and not

                  addEventListener(...)

                  because the implicit form fails in strict mode. When a function is called as
                  a function, this will be bound to undefined. In sloppy mode, this was bound
                  to the global object, which was a bad idea, which enabled the implicit form,
                  which was also a bad idea.
                • Douglas Crockford
                  ... They are global functions, not methods of the window object, so they work correctly without the window. prefix.
                  Message 8 of 8 , Feb 11, 2011
                  View Source
                  • 0 Attachment
                    --- In jslint_com@yahoogroups.com, "Rob Richardson" <erobrich@...> wrote:
                    >
                    > I see setTimeout (and cousins) are still in the browser defined list, but
                    > would you recomend the same rule of thumb be true for these? E.g. would you
                    > recommend "window.setTimeout( func...." rather than "setTimeout( func...."?


                    They are global functions, not methods of the window object, so they work correctly without the window. prefix.
                  Your message has been successfully submitted and would be delivered to recipients shortly.