document.all

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • James Moe

    document.all

    Hello,
    1. The document.all property (array?) seems to be a popular IE-only
    attribute. Other browsers (Opera, Mozilla) do not seem to care for it which,
    of course, occasionally produces weird displays and non-functional links.
    Is it, indeed, a IE-ism?

    2. While experimenting with the elusive document.all, I ran into a sort of
    catch-22, it least with Mozilla. I tried testing (null == document.all) to
    decide if the property exists, and get a warning (in the Mozilla Javascript
    console) that the property does not exist. Hm.
    Is there a robust way to test for a property that may not exist? A way
    that does not generate warnings or errors about that non-existence?

    --
    jim moe
  • Randy Webb

    #2
    Re: document.all

    James Moe wrote:[color=blue]
    > Hello,
    > 1. The document.all property (array?) seems to be a popular IE-only
    > attribute. Other browsers (Opera, Mozilla) do not seem to care for it
    > which, of course, occasionally produces weird displays and
    > non-functional links.
    > Is it, indeed, a IE-ism?[/color]

    Yes.
    [color=blue]
    > 2. While experimenting with the elusive document.all, I ran into a sort
    > of catch-22, it least with Mozilla. I tried testing (null ==
    > document.all) to decide if the property exists, and get a warning (in
    > the Mozilla Javascript console) that the property does not exist. Hm.[/color]

    Thats because you are testing null against document.all, since
    document.all doesn't exist in Mozilla, you get the error.

    [color=blue]
    > Is there a robust way to test for a property that may not exist? A way
    > that does not generate warnings or errors about that non-existence?[/color]

    if (document.all)
    {
    //it exists
    }

    or

    if (!document.all)
    {
    //it doesn't exist
    }

    depending on what you are doing.


    --
    Randy
    Chance Favors The Prepared Mind
    comp.lang.javas cript FAQ - http://jibbering.com/faq/

    Comment

    • James Moe

      #3
      Re: document.all

      Randy Webb wrote:[color=blue]
      >[color=green]
      >> Is there a robust way to test for a property that may not exist? A
      >> way that does not generate warnings or errors about that non-existence?[/color]
      >
      > if (document.all)
      > {
      > //it exists
      > }
      >[/color]
      Thank you.

      --
      jim moe

      Comment

      • Richard Cornford

        #4
        Re: document.all

        James Moe wrote:[color=blue]
        > 1. The document.all property (array?) seems to be a popular IE-only
        > attribute. Other browsers (Opera, Mozilla) do not seem to care for it[/color]

        Opera 7, and many other browsers do implement a document.all collection.
        But most also support a W3C DOM standard alternative (as do recent IE
        versions) so their use should be preferred and document.all relegated to
        the status of potential fall-back for 2 or 3 dinosaur browsers.
        [color=blue]
        > which, of course, occasionally produces weird displays and
        > non-functional links. Is it, indeed, a IE-ism?[/color]

        It certainly originated at Microsoft in IE. Its imitation by many other
        browsers was out of expedience rather than need.
        [color=blue]
        > 2. While experimenting with the elusive document.all, I ran into a
        > sort of catch-22, it least with Mozilla. I tried testing
        > (null == document.all)[/color]

        Comparison with - null - is not the best test. A direct type-converting
        to boolean test will produce false for null and undefined and true for
        objects and functions.
        [color=blue]
        > to decide if the property exists, and get a warning (in
        > the Mozilla Javascript console) that the property does not exist. Hm.[/color]

        Yes, they are berks! They are attempting to apply warning criteria that
        make prefect sense when authoring for a known environment in a
        non-dynamic language. An no doubt when they write javascript it is for
        Mozilla, so they have a known environment and accessing an unimplemented
        property would be a mistake. But cross-browser scripting has to exploit
        the dynamic nature of javascript and applying an operation that will
        type-convert an undefined property into a false boolean value is a
        completely valid, normal and (for efficiency at least) desirable
        operation.

        If you are not writing exclusively for Mozilla ignore Mozilla's
        warnings. If you want warnings relating to javascript authoring use
        JSLINT.
        [color=blue]
        > Is there a robust way to test for a property that may not exist? A
        > way that does not generate warnings or errors about that
        > non-existence?[/color]

        Yes, the - typeof - operator can be used for all testing, it is even
        necessary to use it to verify some aspects of the environment, such as
        determining if properties refer to primitive values because a
        type-converting test will produce false results with empty strings,
        numeric zero and boolean false (though no type converting is needed for
        that). So - if(typeof pageXOffset == 'number') will tell you that the -
        pageXOffset - property is implemented on the browser even when the value
        of the number is zero (which it usually is, at least initially). But
        notice that the - typeof - test is not one operation it is two, the -
        typeof - operation itself followed by string comparison. String
        comparison should be fairly quick if the strings don't match, comparing
        the first letter will tell you that, but if they do match each letter is
        going to have to be compared in turn and that is much more involved.

        But when dealing with properties that may be implemented as object or
        function a type-converting test will tell you what you want to know in
        one quick and simple operation while - typeof - testing would require a
        battery of tests to give the same information.

        For example, consider the - nextSibling - property of DOM Nodes. The
        possibilities are:-

        1. It is not implemented, its value is - undefined -, so no attempt
        should be made to use it.
        2. It is implemented but there is no nextSibling object, the
        property value is - null - (or possibly - undefined -, though
        that is unlikely), so no attempt should be made to use it.
        3. It is implemented and refers to a sibling Node, Possible typeofs
        are "object" or "function" because of diverse host environment
        implementations . It is safe to interact with the object.

        Obviously the reason for testing the - nextSibling - property is to
        decide whether to interact with the object. So the - tyoeof - test would
        need to see if the returned string was either "object" or "function"
        before acting on the node. But (typeof null == "object") so the test
        would also have to differentiate between - null - and a real DOM node,
        which takes a type-converting test. You can avoid the Mozilla warning by
        doing the - typeof - testing first but the result is:-

        if(((typeof node.nextSiblin g == 'object')||
        (tyoeof node.nextSiblin g == 'function'))&&
        node.nextSiblin g){
        ... // safe to use node.nextSiblin g.
        }

        So that is two - typeof - operations (though it could be got down to one
        with an assignment to a local variable), two string comparisons and a
        type-conversion (not to mention the logical operations) in order to find
        out if it is possible to use the node. Compare that with a normal
        type-converting test:-

        if(node.nextSib ling){
        ... // safe to use node.nextSiblin g.
        }

        It differentiates 100% between - null - and - undefined - on one side
        and objects and functions on the other. And it is a completely legal
        operation in javascript (and all ECMAScript implementations ), indeed it
        is optimum for the task.

        If the authors of Mozilla don't know enough about javascript or browser
        scripting to see that they are doing nothing more worthwhile that
        burdening their (already often sluggish) browser with generating
        meaningless warnings as the result of normal (even advisable) operations
        then that is their own look-out. Giving in to their nonsense means
        burdening every other browser in existence with inefficient code for no
        good reason, and Mozilla is not the only browser in use.

        Richard.


        Comment

        • Mark Preston

          #5
          Re: document.all

          James Moe wrote:[color=blue]
          >
          > 1. The document.all property (array?) seems to be a popular IE-only
          > attribute. [snip]
          > Is it, indeed, a IE-ism?
          >[/color]
          Yes.[color=blue]
          >
          > 2. While experimenting with the elusive document.all, I ran into a sort
          > of catch-22, it least with Mozilla.[snip]
          >[/color]
          Using "document.a ll" is sort of risky, since a lot of browsers don't use
          it at all. Its rather like trying to use your car ignition key to start
          up a helicopter - its not possible, so don't even try.

          --
          Mark A. Preston

          Comment

          • James Moe

            #6
            Re: document.all

            Richard Cornford wrote:[color=blue]
            >[color=green]
            >> Is there a robust way to test for a property that may not exist? A
            >>way that does not generate warnings or errors about that
            >>non-existence?[/color]
            >
            > Yes, the - typeof - operator can be used for all testing, it is even
            > necessary to use it to verify some aspects of the environment, such as
            > determining if properties refer to primitive values [...]
            >[/color]
            Thank you. That is what I was looking for.

            --
            jim moe

            Comment

            Working...