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/JavaSc...ment-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

[Aaron Gray]

"Henry" <rc*******@raindrop.co.ukwrote in message
news:ec**********************************@79g2000h sk.googlegroups.com...

On Aug 1, 1:22 am, Aaron Gray wrote:

>"Aaron Gray" wrote:

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

>> function isElement( o)
{
return o instanceof Element
}

This fails because it cannot be used universally, and will result in
different behaviours accross browsers if used as the general case with a
sub
case for |IE.

>>It works for FF, Opera and Safari.

>>What prototype does is this :-

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

As Henry says this will fail with a typing error if object
is not an object.

I did not say that. I said that an - in - operation would throw an
exception if its subject (right hand side operand) was not an object.
The above is completely safe in ECMAScript terms when the - object -
parameter is not a host object (and also safe with the vast majority
of host objects) because if the value as a primitive it must have
truness to pass the first type-converting test and if it has truness
it can be implicitly type-converted into an object by the dot
operator.

Sorry Henry, it was late and I did not read your reply properly.

So no Object test then.

Aaron

[Aaron Gray]

"Henry" <rc*******@raindrop.co.ukwrote in message
news:83**********************************@k30g2000 hse.googlegroups.com...

On Jul 30, 3:33 pm, Aaron Gray wrote:

>Henry wrote:

>>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.

Whatever you may think, or may prefer, the second branch is the one
based upon documented (W3C) standard behaviour.

The world is upside down in my view :)

>I take your point. But the first test is faster and more
accurate and runs on more browsers.

The first test is not significantly more accurate, as it is still
trivial to fool. But even so, a more accurate test in one branch is
more likely to result in issues that get through testing unnoticed
that consistent behaviour in all environments. Imagine someone who
only tests on, say, Firefox and Safari and the test successfully
rejecting its subjects, but then being released and exposed to IE
where the test lets objects passed that it should not.

Okay, or not okay :)

>>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).

<snip>

How does a test that would fail on at least two current browsers and
dozens of older DOM standard browsers 'run on more browsers' than a
test that would work consistently with all?

Right.

Whether the first test is faster is something that you will have to
demonstrate, but the difference is likely to be small compared with
the overheads of the function call and the test for the branching.

Yes.

At the point of getting each of these two structures you knew
precisely which you had. You knew that because mechanism for
retrieving DOM fragments/branches don't retrieve native JS object
structures, and methods for retrieving JSON structures don't result in
DOM branches. If at some later point you have lost that information
then it is because you threw it away. You solve your problem by
keeping the information you had, not trying to recover it through
dubious inferences.

Yes, One is from inline HTML retrieved by using a getElementById the other
Object notation either inline or from AJAX.

So I need two constructors or a constructor and two initializers or two
factories.

Remember that while javascript can do a crude emulation of method
overloading it is clunky when its subjects are native JS objects, and
hugely problematic when they are host objects (nearly all the
'popular' libraries have got themselves into a mess attempting to
handle this).

Right.

We know that you knew what the object was when you acquired it, at
that should always be the case in your javascript code (it is part of
the programmer's discipline to keep track of the object types in their
code, because there is no language type-system to do that for them).
And knowing the type of object you have you are in a position to chose
an appropriate function method to call with that type as an argument.
That is a lot easier to program, and much more efficient, than having
fewer functions/methods buy having them jump through hoop trying to
work out what types of arguments they received and how they should be
behaving as a result.

Okay, I dont like it but thats my problem, if I am going to write a wigets
library and core support library for others to use I am going to have to
follow your advice.

Its a real shame ECMA-262 allowed a spit in the browsers typing system like
this :(

Thanks for your patients Henry,

Aaron

[Henry]

On Aug 3, 1:41 pm, Aaron Gray wrote:

Henry wrote in message

>On Aug 1, 1:22 am, Aaron Gray wrote:

>>"Aaron Gray" wrote:

<snip>

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

<snip>

So no Object test then.

If you mean the first type-converting test then you need to keep that
in one form or another because you should reject null an undefined
values for the - object - parameter as neither can be type-converted
into an object and so the - object.nodeType - expression will cause an
exception to be thrown.

[Henry]

On Aug 3, 4:24 pm, Aaron Gray wrote:

Henry wrote in message

>On Jul 30, 3:33 pm, Aaron Gray wrote:

>>Henry wrote:
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.

>Whatever you may think, or may prefer, the second branch is the
one based upon documented (W3C) standard behaviour.

The world is upside down in my view :)

The world is what it is.

<snip>

>At the point of getting each of these two structures you knew
precisely which you had. You knew that because mechanism for
retrieving DOM fragments/branches don't retrieve native JS
object structures, and methods for retrieving JSON structures
don't result in DOM branches. If at some later point you have
lost that information then it is because you threw it away.
You solve your problem by keeping the information you had,
not trying to recover it through dubious inferences.

Yes, One is from inline HTML retrieved by using a getElementById
the other Object notation either inline or from AJAX.

So I need two constructors or a constructor and two
initializers or two factories.

Or any of 100-odd other possibilities.

<snip>

>We know that you knew what the object was when you acquired
it, at that should always be the case in your javascript
code (it is part of the programmer's discipline to keep track
of the object types in their code, because there is no language
type-system to do that for them). And knowing the type of
object you have you are in a position to chose an appropriate
function method to call with that type as an argument. That is
a lot easier to program, and much more efficient, than having
fewer functions/methods buy having them jump through hoop
trying to work out what types of arguments they received and
how they should be behaving as a result.

Okay, I dont like it but thats my problem, if I am going to
write a wigets library and core support library for others
to use I am going to have to follow your advice.

You don't have to do anything of the sort. Obviously I would take may
own advice but there have been plenty who have had the opportunity and
not done so ;-)

Its a real shame ECMA-262 allowed a spit in the browsers
typing system like this :(

<snip>

What? ECMA has nothing to do with browsers (except by coincidence).
ECMA 262 is the language specification, it is the W3C who do browser
object model specifications, and not always as smartly, completely or
realistically as they could.