isElement - determining if an object is an element

[Aaron Gray]

Due to M$'s stupidity in not making DOMElements first class citizens the
following will not work :-

function isElement( o)
{
return o instanceof Element
}

It works for FF, Opera and Safari.

What prototype does is this :-

isElement: function(object ) {
return object && object.nodeType == 1
}

My version used Browser sniffing :-

function isElement( o)
{
if (!isIE)
return o instanceof Element
else
return o && o.nodeType == 1 && o.tagName != undefined
}

Test case :-

http://www.aarongray.org/Test/JavaScript/isElement-test.html

The actual 'isIE' test code is not the best but is used for brevity.

Any crevats, problems or enhancements most welcome.

Thanks,

Aaron

[Henry]

Re: isElement - determining if an object is an element

On Jul 30, 2:46 pm, Aaron Gray wrote:
<snip>

function isElement( o)
{
if (!isIE)
return o instanceof Element
else
return o && o.nodeType == 1 && o.tagName != undefined
}

<snip>

Why branch for this? If the second test is ever good enough it is
always good enough.

Exact equality (===) with 1 would be more precise than type-converting
equality and reduce the possible false positives.

But overall what it the point? If you inferred from a true result from
a call to your - isElement - method that the object implemented the
whole W3C Core DOM (Level 1 or 2) Element interface you would be wrong
in a number of cases. It would make more sense to decide what features
you wanted from such an element and test for those alone on a basis
driven by need.

[Aaron Gray]

Re: isElement - determining if an object is an element

"Henry" <rcornford@rain drop.co.ukwrote in message
news:35321f53-d3d9-4908-ab4a-7a26b27ea6d5@2g 2000hsn.googleg roups.com...

On Jul 30, 2:46 pm, Aaron Gray wrote:
<snip>

> function isElement( o)
> {
> if (!isIE)
> return o instanceof Element
> else
> return o && o.nodeType == 1 && o.tagName != undefined
> }

<snip>
>
Why branch for this? If the second test is ever good enough it is
always good enough.

Because I would like to use "conforming " browser traits, not that this is
actually one, but it should have been in my view. I take your point. But the
first test is faster and more accurate and runs on more browsers.

Exact equality (===) with 1 would be more precise than type-converting
equality and reduce the possible false positives.

Yes forgot to change that. Thanks,

But overall what it the point? If you inferred from a true result from
a call to your - isElement - method that the object implemented the
whole W3C Core DOM (Level 1 or 2) Element interface you would be wrong
in a number of cases. It would make more sense to decide what features
you wanted from such an element and test for those alone on a basis
driven by need.

Basically my library widget constructors either take a DOM structure,
normally the enclosing DIV (which is what I was wanting to test for) or a
JSON like object which describes the object, directly (or over AJAX).

Thanks for the feedback,

Aaron

[Aaron Gray]

Re: isElement - determining if an object is an element

"Aaron Gray" <ang.usenet@gma il.comwrote in message
news:6fbcesFaqc m6U1@mid.indivi dual.net...

"Henry" <rcornford@rain drop.co.ukwrote in message
news:35321f53-d3d9-4908-ab4a-7a26b27ea6d5@2g 2000hsn.googleg roups.com...

>On Jul 30, 2:46 pm, Aaron Gray wrote:
><snip>

>> function isElement( o)
>> {
>> if (!isIE)
>> return o instanceof Element
>> else
>> return o && o.nodeType == 1 && o.tagName != undefined
>> }

><snip>
>>
>Why branch for this? If the second test is ever good enough it is
>always good enough.

>
Because I would like to use "conforming " browser traits, not that this is
actually one, but it should have been in my view. I take your point. But
the first test is faster and more accurate and runs on more browsers.
>

>Exact equality (===) with 1 would be more precise than type-converting
>equality and reduce the possible false positives.

>
Yes forgot to change that. Thanks,
>

>But overall what it the point? If you inferred from a true result from
>a call to your - isElement - method that the object implemented the
>whole W3C Core DOM (Level 1 or 2) Element interface you would be wrong
>in a number of cases. It would make more sense to decide what features
>you wanted from such an element and test for those alone on a basis
>driven by need.

>
Basically my library widget constructors either take a DOM structure,
normally the enclosing DIV (which is what I was wanting to test for) or a
JSON like object which describes the object, directly (or over AJAX).

So here's a more effiecient version

if (!isIE)
var isElement = function( o)
{
return o instanceof Element
}
else
var isElement = function( o)
{
return o && o.nodeType === 1 && o.tagName !== undefined
}

As per usual any critisms are welcome :)

Thanks,

Aaron

[Aaron Gray]

Re: isElement - determining if an object is an element

"Aaron Gray" <ang.usenet@gma il.comwrote in message
news:6fbh2hFasp nvU1@mid.indivi dual.net...

"Aaron Gray" <ang.usenet@gma il.comwrote in message
news:6fbcesFaqc m6U1@mid.indivi dual.net...

>"Henry" <rcornford@rain drop.co.ukwrote in message
>news:35321f5 3-d3d9-4908-ab4a-7a26b27ea6d5@2g 2000hsn.googleg roups.com...

>>On Jul 30, 2:46 pm, Aaron Gray wrote:
>><snip>
>>> function isElement( o)
>>> {
>>> if (!isIE)
>>> return o instanceof Element
>>> else
>>> return o && o.nodeType == 1 && o.tagName != undefined
>>> }
>><snip>
>>>
>>Why branch for this? If the second test is ever good enough it is
>>always good enough.

>>
>Because I would like to use "conforming " browser traits, not that this is
>actually one, but it should have been in my view. I take your point. But
>the first test is faster and more accurate and runs on more browsers.
>>

>>Exact equality (===) with 1 would be more precise than type-converting
>>equality and reduce the possible false positives.

>>
>Yes forgot to change that. Thanks,
>>

>>But overall what it the point? If you inferred from a true result from
>>a call to your - isElement - method that the object implemented the
>>whole W3C Core DOM (Level 1 or 2) Element interface you would be wrong
>>in a number of cases. It would make more sense to decide what features
>>you wanted from such an element and test for those alone on a basis
>>driven by need.

>>
>Basically my library widget constructors either take a DOM structure,
>normally the enclosing DIV (which is what I was wanting to test for) or a
>JSON like object which describes the object, directly (or over AJAX).

>
So here's a more effiecient version
>
if (!isIE)
var isElement = function( o)
{
return o instanceof Element
}
else
var isElement = function( o)
{
return o && o.nodeType === 1 && o.tagName !== undefined
}
>
As per usual any critisms are welcome :)

There's an updated test here :-

http://www.aarongray.org/Test/JavaScript/isElement-test2.html

Thanks,

Aaron

[David Mark]

Re: isElement - determining if an object is an element

On Jul 30, 11:52 am, "Aaron Gray" <ang.use...@gma il.comwrote:

"Aaron Gray" <ang.use...@gma il.comwrote in message
>
news:6fbcesFaqc m6U1@mid.indivi dual.net...
>
>
>

"Henry" <rcornf...@rain drop.co.ukwrote in message
news:35321f53-d3d9-4908-ab4a-7a26b27ea6d5@2g 2000hsn.googleg roups.com...

On Jul 30, 2:46 pm, Aaron Gray wrote:
<snip>
>    function isElement( o)
>    {
>        if (!isIE)
>            return o instanceof Element
>        else
>            return o && o.nodeType == 1 && o.tagName != undefined
>    }
<snip>

>

Why branch for this? If the second test is ever good enough it is
always good enough.

>

Because I would like to use "conforming " browser traits, not that this is
actually one, but it should have been in my view. I take your point. But
the first test is faster and more accurate and runs on more browsers.

>

Exact equality (===) with 1 would be more precise than type-converting
equality and reduce the possible false positives.

>

Yes forgot to change that. Thanks,

>

But overall what it the point? If you inferred from a true result from
a call to your - isElement - method that the object implemented the
whole W3C Core DOM (Level 1 or 2) Element interface you would be wrong
in a number of cases. It would make more sense to decide what features
you wanted from such an element and test for those alone on a basis
driven by need.

>

Basically my library widget constructors either take a DOM structure,
normally the enclosing DIV (which is what I was wanting to test for) ora
JSON like object which describes the object, directly (or over AJAX).

>
So here's a more effiecient version
>
     if (!isIE)
        var isElement = function( o)
        {
             return o instanceof Element
        }
    else
        var isElement = function( o)
        {
             return o && o.nodeType === 1 && o.tagName !== undefined
        }
>
As per usual any critisms are welcome :)
>
Thanks,
>
Aaron

o.tagName != '!'

Lose the sniffing branch and use typeof to determine if o.tagName is a
string and o.nodeType is a number (IE can blow up otherwise.)

As Richard noted, it is likely that you can design this function out
of your application.

[Aaron Gray]

Re: isElement - determining if an object is an element

"David Mark" <dmark.cinsoft@ gmail.comwrote in message
news:92dfaa86-00cf-42d6-9c85-3784128d7e4d@k3 7g2000hsf.googl egroups.com...
On Jul 30, 11:52 am, "Aaron Gray" <ang.use...@gma il.comwrote:

"Aaron Gray" <ang.use...@gma il.comwrote in message
>
news:6fbcesFaqc m6U1@mid.indivi dual.net...
>
>
>

"Henry" <rcornf...@rain drop.co.ukwrote in message
news:35321f53-d3d9-4908-ab4a-7a26b27ea6d5@2g 2000hsn.googleg roups.com...

On Jul 30, 2:46 pm, Aaron Gray wrote:
<snip>
>function isElement( o)
>{
>if (!isIE)
>return o instanceof Element
>else
>return o && o.nodeType == 1 && o.tagName != undefined
>}
<snip>

>

Why branch for this? If the second test is ever good enough it is
always good enough.

>

Because I would like to use "conforming " browser traits, not that this
is
actually one, but it should have been in my view. I take your point. But
the first test is faster and more accurate and runs on more browsers.

>

Exact equality (===) with 1 would be more precise than type-converting
equality and reduce the possible false positives.

>

Yes forgot to change that. Thanks,

>

But overall what it the point? If you inferred from a true result from
a call to your - isElement - method that the object implemented the
whole W3C Core DOM (Level 1 or 2) Element interface you would be wrong
in a number of cases. It would make more sense to decide what features
you wanted from such an element and test for those alone on a basis
driven by need.

>

Basically my library widget constructors either take a DOM structure,
normally the enclosing DIV (which is what I was wanting to test for) or
a
JSON like object which describes the object, directly (or over AJAX).

>
So here's a more effiecient version
>
if (!isIE)
var isElement = function( o)
{
return o instanceof Element
}
else
var isElement = function( o)
{
return o && o.nodeType === 1 && o.tagName !== undefined
}
>
As per usual any critisms are welcome :)
>
Thanks,
>
Aaron

<o.tagName != '!'

<Lose the sniffing branch and use typeof to determine if o.tagName is a
<string and o.nodeType is a number (IE can blow up otherwise.)

Okay so the IE version is not strict enough checking wise not to fall over,
yes, I had half expected that. Okay I will have to look into this better.
Surely the o.nodeType === 1 check is okay. Heres a mod :-

var isElement = function( o)
{
return o && o.nodeType === 1 && typeof o.tagName === string
}

<As Richard noted, it is likely that you can design this function out
<of your application.

My "App" or widget library really wants a good standard function to do th
job that is easy to read, understand and document for other Widget writters.
I get your point though for apps, but then readability and maintainiabily
also apply there as well.

Thanks,

Aaron

[Aaron Gray]

Re: isElement - determining if an object is an element

"Aaron Gray" <ang.usenet@gma il.comwrote in message
news:6fbk59Famn 20U1@mid.indivi dual.net...

"David Mark" <dmark.cinsoft@ gmail.comwrote in message
news:92dfaa86-00cf-42d6-9c85-3784128d7e4d@k3 7g2000hsf.googl egroups.com...
On Jul 30, 11:52 am, "Aaron Gray" <ang.use...@gma il.comwrote:

>"Aaron Gray" <ang.use...@gma il.comwrote in message
>>
>news:6fbcesFaq cm6U1@mid.indiv idual.net...
>>
>>
>>

"Henry" <rcornf...@rain drop.co.ukwrote in message
>news:35321f5 3-d3d9-4908-ab4a-7a26b27ea6d5@2g 2000hsn.googleg roups.com...
>On Jul 30, 2:46 pm, Aaron Gray wrote:
><snip>
>>function isElement( o)
>>{
>>if (!isIE)
>>return o instanceof Element
>>else
>>return o && o.nodeType == 1 && o.tagName != undefined
>>}
><snip>

>>

>Why branch for this? If the second test is ever good enough it is
>always good enough.

>>

Because I would like to use "conforming " browser traits, not that this
is
actually one, but it should have been in my view. I take your point.
But
the first test is faster and more accurate and runs on more browsers.

>>

>Exact equality (===) with 1 would be more precise than type-converting
>equality and reduce the possible false positives.

>>

Yes forgot to change that. Thanks,

>>

>But overall what it the point? If you inferred from a true result from
>a call to your - isElement - method that the object implemented the
>whole W3C Core DOM (Level 1 or 2) Element interface you would be wrong
>in a number of cases. It would make more sense to decide what features
>you wanted from such an element and test for those alone on a basis
>driven by need.

>>

Basically my library widget constructors either take a DOM structure,
normally the enclosing DIV (which is what I was wanting to test for) or
a
JSON like object which describes the object, directly (or over AJAX).

>>
>So here's a more effiecient version
>>
>if (!isIE)
>var isElement = function( o)
>{
>return o instanceof Element
>}
>else
>var isElement = function( o)
>{
>return o && o.nodeType === 1 && o.tagName !== undefined
>}
>>
>As per usual any critisms are welcome :)
>>
>Thanks,
>>
>Aaron

>
<o.tagName != '!'
>
<Lose the sniffing branch and use typeof to determine if o.tagName is a
<string and o.nodeType is a number (IE can blow up otherwise.)

What do you mean IE can blow up otherwise ? Sule the instanceof should hold
fine.

I am keeping the IE version for speeds sake mainly.

Okay so the IE version is not strict enough checking wise not to fall
over, yes, I had half expected that. Okay I will have to look into this
better. Surely the o.nodeType === 1 check is okay. Heres a mod :-
>
var isElement = function( o)
{
return o && o.nodeType === 1 && typeof o.tagName === string
}
>

Whoopse string needs to be in quotes !

Aaron

[David Mark]

Re: isElement - determining if an object is an element

On Jul 30, 12:45 pm, "Aaron Gray" <ang.use...@gma il.comwrote:

"David Mark" <dmark.cins...@ gmail.comwrote in message
>
news:92dfaa86-00cf-42d6-9c85-3784128d7e4d@k3 7g2000hsf.googl egroups.com...
On Jul 30, 11:52 am, "Aaron Gray" <ang.use...@gma il.comwrote:
>
>
>

"Aaron Gray" <ang.use...@gma il.comwrote in message

>

news:6fbcesFaqc m6U1@mid.indivi dual.net...

>

"Henry" <rcornf...@rain drop.co.ukwrote in message
>news:35321f5 3-d3d9-4908-ab4a-7a26b27ea6d5@2g 2000hsn.googleg roups.com....
>On Jul 30, 2:46 pm, Aaron Gray wrote:
><snip>
>>function isElement( o)
>>{
>>if (!isIE)
>>return o instanceof Element
>>else
>>return o && o.nodeType == 1 && o.tagName != undefined
>>}
><snip>

>

>Why branch for this? If the second test is ever good enough it is
>always good enough.

>

Because I would like to use "conforming " browser traits, not that this
is
actually one, but it should have been in my view. I take your point. But
the first test is faster and more accurate and runs on more browsers.

>

>Exact equality (===) with 1 would be more precise than type-converting
>equality and reduce the possible false positives.

>

Yes forgot to change that. Thanks,

>

>But overall what it the point? If you inferred from a true result from
>a call to your - isElement - method that the object implemented the
>whole W3C Core DOM (Level 1 or 2) Element interface you would be wrong
>in a number of cases. It would make more sense to decide what features
>you wanted from such an element and test for those alone on a basis
>driven by need.

>

Basically my library widget constructors either take a DOM structure,
normally the enclosing DIV (which is what I was wanting to test for) or
a
JSON like object which describes the object, directly (or over AJAX).

>

So here's a more effiecient version

>

if (!isIE)
var isElement = function( o)
{
return o instanceof Element
}
else
var isElement = function( o)
{
return o && o.nodeType === 1 && o.tagName !== undefined
}

>

As per usual any critisms are welcome :)

>

Thanks,

>

Aaron

>
<o.tagName != '!'
>
<Lose the sniffing branch and use typeof to determine if o.tagName is a
<string and o.nodeType is a number (IE can blow up otherwise.)
>
Okay so the IE version is not strict enough checking wise not to fall over,
yes, I had half expected that. Okay I will have to look into this better.
Surely the o.nodeType === 1 check is okay. Heres a mod :-

No. Try it with an anchor in IE7 that points to a news resource or an
element in a fragment, etc. Always use typeof to test host object
properties.

>
var isElement = function( o)
{
    return o && o.nodeType === 1 && typeof o.tagName === string
>
}
>
<As Richard noted, it is likely that you can design this function out
<of your application.
>
My "App" or widget library really wants a good standard function to do th

I'm not sure what a "widget library" is.

job that is easy to read, understand and document for other Widget writters.

You already lost that battle if you must expose such a function in
your API. If you are using it to validate arguments passed to your
methods, document acceptable arguments instead.

[RobG]

Re: isElement - determining if an object is an element

On Jul 30, 11:46 pm, "Aaron Gray" <ang.use...@gma il.comwrote:

Due to M$'s stupidity in not making DOMElements first class citizens the
following will not work :-
>
    function isElement( o)
    {
        return o instanceof Element
    }
>
It works for FF, Opera and Safari.
>
What prototype does is this :-
>
        isElement: function(object ) {
            return object && object.nodeType == 1
        }
>
My version used Browser sniffing :-
>
        function isElement( o)
        {
            if (!isIE)
                return o instanceof Element
            else
                return o && o.nodeType == 1 && o.tagName != undefined
        }
>

Noting the other advice given here, and that IE 8 will not support
enumeration of nodeType constant values, the following should suit

function isElement(o) {
return o && o.nodeType &&
(o.ELEMENT_NODE === o.nodeType || o.nodeType === 1);
}

Given that you are really trying to distinguish between a DOM node and
a JSON string, why not:

if (typeof o === 'string') {
// assume JSON
} else {
// assume element
}


--
Rob

[Aaron Gray]

Re: isElement - determining if an object is an element


"RobG" <rgqld@iinet.ne t.auwrote in message
news:57e97d0b-33f7-4198-b0ae-e9dc04dc4e36@r3 5g2000prm.googl egroups.com...
On Jul 30, 11:46 pm, "Aaron Gray" <ang.use...@gma il.comwrote:

Due to M$'s stupidity in not making DOMElements first class citizens the
following will not work :-
>
function isElement( o)
{
return o instanceof Element
}
>
It works for FF, Opera and Safari.
>
What prototype does is this :-
>
isElement: function(object ) {
return object && object.nodeType == 1
}
>
My version used Browser sniffing :-
>
function isElement( o)
{
if (!isIE)
return o instanceof Element
else
return o && o.nodeType == 1 && o.tagName != undefined
}
>

<Noting the other advice given here, and that IE 8 will not support
<enumeration of nodeType constant values, the following should suit
<
<function isElement(o) {
< return o && o.nodeType &&
< (o.ELEMENT_NODE === o.nodeType || o.nodeType === 1);
<}

This is messy. My code worked fine on IE8. BTW Just removed IE8 due to other
issues, like behavioual bugs.

<Given that you are really trying to distinguish between a DOM node and
<a JSON string, why not:

Its not a JSON string but an diseminated object at this stage that comes
from a JSON object.

Thanks,

Aaron

[Aaron Gray]

Re: isElement - determining if an object is an element

"David Mark" <dmark.cinsoft@ gmail.comwrote in message
news:494577ca-eb6f-4b43-acbe-433624e795a2@z6 6g2000hsc.googl egroups.com...
On Jul 30, 12:45 pm, "Aaron Gray" <ang.use...@gma il.comwrote:

"David Mark" <dmark.cins...@ gmail.comwrote in message
>
news:92dfaa86-00cf-42d6-9c85-3784128d7e4d@k3 7g2000hsf.googl egroups.com...
On Jul 30, 11:52 am, "Aaron Gray" <ang.use...@gma il.comwrote:
>
>
>

"Aaron Gray" <ang.use...@gma il.comwrote in message

>

news:6fbcesFaqc m6U1@mid.indivi dual.net...

>

"Henry" <rcornf...@rain drop.co.ukwrote in message
>news:35321f5 3-d3d9-4908-ab4a-7a26b27ea6d5@2g 2000hsn.googleg roups.com...
>On Jul 30, 2:46 pm, Aaron Gray wrote:
><snip>
>>function isElement( o)
>>{
>>if (!isIE)
>>return o instanceof Element
>>else
>>return o && o.nodeType == 1 && o.tagName != undefined
>>}
><snip>

>

>Why branch for this? If the second test is ever good enough it is
>always good enough.

>

Because I would like to use "conforming " browser traits, not that this
is
actually one, but it should have been in my view. I take your point.
But
the first test is faster and more accurate and runs on more browsers.

>

>Exact equality (===) with 1 would be more precise than
>type-converting
>equality and reduce the possible false positives.

>

Yes forgot to change that. Thanks,

>

>But overall what it the point? If you inferred from a true result
>from
>a call to your - isElement - method that the object implemented the
>whole W3C Core DOM (Level 1 or 2) Element interface you would be
>wrong
>in a number of cases. It would make more sense to decide what
>features
>you wanted from such an element and test for those alone on a basis
>driven by need.

>

Basically my library widget constructors either take a DOM structure,
normally the enclosing DIV (which is what I was wanting to test for)
or
a
JSON like object which describes the object, directly (or over AJAX).

>

So here's a more effiecient version

>

if (!isIE)
var isElement = function( o)
{
return o instanceof Element
}
else
var isElement = function( o)
{
return o && o.nodeType === 1 && o.tagName !== undefined
}

>

As per usual any critisms are welcome :)

>

Thanks,

>

Aaron

>
<o.tagName != '!'
>
<Lose the sniffing branch and use typeof to determine if o.tagName is a
<string and o.nodeType is a number (IE can blow up otherwise.)
>
Okay so the IE version is not strict enough checking wise not to fall
over,
yes, I had half expected that. Okay I will have to look into this better.
Surely the o.nodeType === 1 check is okay. Heres a mod :-

<No. Try it with an anchor in IE7 that points to a news resource or an
<element in a fragment, etc. Always use typeof to test host object
<properties.

donot follow could you give me a more explict example or two ?

>
var isElement = function( o)
{
return o && o.nodeType === 1 && typeof o.tagName === string
>
}
>
<As Richard noted, it is likely that you can design this function out
<of your application.
>
My "App" or widget library really wants a good standard function to do th

<I'm not sure what a "widget library" is.

Comes fro Window Gadget, being a tree or a table. See ExtJS 2.0 for a Widget
based library :-

http://extjs.com/

job that is easy to read, understand and document for other Widget
writters.

<You already lost that battle if you must expose such a function in
<your API. If you are using it to validate arguments passed to your
<methods, document acceptable arguments instead.

Its for validation (and the equalient of overloaded function behaviour) and
for core support library functionality. ie other wishing to extend the
library or create new widgets.

Aaron

[kangax]

Re: isElement - determining if an object is an element

On Jul 30, 11:52 am, "Aaron Gray" <ang.use...@gma il.comwrote:

[snip]

So here's a more effiecient version
>
     if (!isIE)
        var isElement = function( o)
        {
             return o instanceof Element
        }
    else
        var isElement = function( o)
        {
             return o && o.nodeType === 1 && o.tagName !== undefined
        }
>
As per usual any critisms are welcome :)

The double function expression is unnecessary.

It could be rewritten like so:

var isElement = (function(){
var el = document.create Element('div'), fn;
if (el instanceof Element) {
fn = function(o) {
return o instanceof Element;
}
}
else {
fn = function(o) {
return o && typeof 'nodeType' in o && o.nodeType === 1;
}
}
el = null;
return fn;
})();

We don't perform such branching in prototype.js to avoid
inconsistencies across browsers.

isElement(docum ent.createEleme nt('div')); // true in IE and FF
isElement({ nodeType: 1 }); // true in IE, but false in FF

--
kangax

[kangax]

Re: isElement - determining if an object is an element

On Jul 31, 12:33 am, kangax <kan...@gmail.c omwrote:

[snip]

  else {
    fn = function(o) {
      return o && typeof 'nodeType' in o && o.nodeType === 1;
    }
  }

That should have been:

...
fn = function(o) {
return o && 'nodeType' in o && o.nodeType === 1;
}
...

--
kangax

[RobG]

Re: isElement - determining if an object is an element

On Jul 31, 10:40 am, "Aaron Gray" <ang.use...@gma il.comwrote:

"RobG" <rg...@iinet.ne t.auwrote in message
>
news:57e97d0b-33f7-4198-b0ae-e9dc04dc4e36@r3 5g2000prm.googl egroups.com...
On Jul 30, 11:46 pm, "Aaron Gray" <ang.use...@gma il.comwrote:
>

Due to M$'s stupidity in not making DOMElements first class citizens the
following will not work :-

>

function isElement( o)
{
return o instanceof Element
}

>

It works for FF, Opera and Safari.

>

What prototype does is this :-

>

isElement: function(object ) {
return object && object.nodeType == 1
}

That should be sufficient everywhere, there is no need for browser
sniffing. However, the function is pretty useless for the reasons
expressed in other posts.

My version used Browser sniffing :-

>

function isElement( o)
{
if (!isIE)
return o instanceof Element
else
return o && o.nodeType == 1 && o.tagName != undefined
}

What is the point of the tagName test? Do you know of a case where
the nodeType test returns true but the tagName test returns false
(even if changed to a typeof comparison)?

>
<Noting the other advice given here, and that IE 8 will not support
<enumeration of nodeType constant values, the following should suit

That turned out to be incorrect advice: I downloaded and installed IE8
Beta 1, element.nodeTyp e property returns appropriate values,
element.ELEMENT _NODE returns undefined.

<
<function isElement(o) {
<  return o && o.nodeType &&
<        (o.ELEMENT_NODE === o.nodeType || o.nodeType === 1);
<}
>
This is messy.

Messy? In hind sight, unnecessarily long.

My code worked fine on IE8.

"Worked" is only sufficient where there is no other criterion that can
be used.

BTW Just removed IE8 due to other
issues, like behavioual bugs.

Thanks for the warning... :-(

<Given that you are really trying to distinguish between a DOM node and
<a JSON string, why not:
>
Its not a JSON string but an diseminated object at this stage that comes
from a JSON object.

The strategy of feature detection is to determine if objects have the
properties you need them to have, rather than whether they have a
particular feature and inferring that they have other features as a
result.

For example, the fact that an object has a nodeType property with a
value of 1 should not infer support for all relevant DOM 2 interface
features (Node, HTMLElement, etc.) which is what might be inferred
from an isElement function.

Therefore, within your code, you might consider a simple test to
distinguish between an element or "diseminate d object" such as
(presuming the other object doesn't have a nodeType property):

if (o.nodeType) {
// o is an element
} else {
// o is something else
}

which does not seem to be any more code than an equivalent isElement()
test (and removes all the code for isElement also).


--
Rob