FAQ Question: How do I detect Opera/Netscape/IE

[Garrett Smith]

kangax wrote:
Conrad Lender wrote:
[...]

[...]

I'm can't prove it was not, but I bet you are wrong on that.

Are you kidding?

Not kidding.

It was an "unknown" type. That's a fact. And it

behaved just as the "unknown" types do in Windows (blows up on type
conversion, among other things.)

So you had an object where:-

typeof obj == "unknown"

was true in Mac IE. I have not seen that and I'm calling you on that. I
think you are mistaken. Please post an example.

That is exactly what I said. I didn't say a thing about Gecko's
developers trying to stay away from it.


I don't know what that means.

Ah, you said:

| Gecko's document.all is an "undefined" type, despite its availability
| (clearly a cue from the Gecko developers to stay away from it.)

My reply is in response to that. Gecko developers were not cuing. They
were trying to make IE-only sites work.

As in refuse.

Are you British?

And?

I wanted to ask: Is what I wrote what you meant? Did you mean: If
isHostMethod(document, "getElementById"); returns true, then you can be
sure that isHostMethod is a host method.

?

That is a true statement and I think that is what you meant but it is
not what you wrote. You wrote:

| If it passes - for example - gEBI, you can be quite sure it is a host
| method.

- not true, if taken literally. Does not make much sense to me.

YES.

That is what isHostMethod does. It does nothing more.

That is *also* the approach for using the |in| operator.

Both are valid approaches. Neither is infallible.

We've discussed this to death.

No argument there.

The first argument is a host

object. Not an Object object or a string or whatever. The second is
the name of a method. Not a name of any other type of property. I
think it is quite clear. The name kind of says it all.

The method requires the developer to know that the second argument is
the name of a method.

Do you see a parallel to the approach using |in| ?

The benefit to |in| is that is inline and does not require stepping into
another line of code in another file.

So, IIUC, isHostMethod detects the presence of a property, and that it
is not a primitive value (it even has to call [[Get]] to do that). Did I
get that right?

Not even in the ballpark. And I don't think you are really trying.

How did you come to that, or why do you say that? Can you respond more
specifically to what I wrote?

That is not what it does. In fact, such a method would be completely
idiotic (see jQuery.) And see above.

It would be well-intentioned, but could not work.

Oh, but it does. Perhaps not in the way you would like, but it is the
only way in reality.

isHostMethod(document, "images");

returns true in all browsers.

But document.images is *not* callable in all browsers.

I don't care what you do with that thing.

I am disappointed to hear that. Yesterday you seemed interested with
what should and should not go into the FAQ.

| We've settled these issues and nothing like this is going in
| the FAQ if I have anything to say about it (and you know I will.)

You said your bit, the proposed change that you agreed to was agreed on
by me, making three of us.

The FAQ is a document for learning and reference.

The FAQ is an accurate collection of knowledge that is critically
reviewed. It is corrected and republished at 0 marginal cost with little
environmental impact. It is a more accurate reference than the books and
videos and other sources of inaccuracies.

The rampant misconception that javascript development requires using a
preconceived library like Dojo can be recognized for what it is by more
people learning.

The FAQ has to get better.

Garrett

 

[Garrett Smith]

These don't have exactly the same meaning, of course.

I don't know that the condition actually exists in reality, but if
e.target is ever null, your alternative will return undefined instead
of null.

Theoretically, the result would be whatever e.srcElement is and that
might not necessarily be undefined. Opera has both.

Garrett

 

[Garrett Smith]

[...]

Are you kidding?

Not kidding.

It was an "unknown" type. That's a fact. And it

behaved just as the "unknown" types do in Windows (blows up on type
conversion, among other things.)

So you had an object where:-

typeof obj == "unknown"

was true in Mac IE. I have not seen that and I'm calling you on that. I
think you are mistaken. Please post an example.

You've been called out on that and no reply.

No "unknown" type in Mac IE.

[...]

Ah, you said:

| Gecko's document.all is an "undefined" type, despite its availability
| (clearly a cue from the Gecko developers to stay away from it.)

My reply is in response to that. Gecko developers were not cuing. They
were trying to make IE-only sites work.

And again, wrong on that one.

[...]

The FAQ has to get better.

Updated:
Version 16, Updated June 04, 2009 by Garrett Smith
http://jibbering.com/faq/#detectBrowser

Also added a rule to faq.css so that the hover effect does not affect
named anchor in h3 and the h3 has a little more margin-top (1.5em), as
requested. It seems less squished and provides a little space between an
answer and the following question.

Garrett -> To gym.

 

[Eric Bednarz]

Garrett Smith wrote:

David Mark wrote:
[…] the most mysterious
Mac IE bug I'd ever seen. Sure enough, it was an "unknown" type.

You've been called out on that and no reply.

I remember reading stuff like that in Heavy Metal magazines
when I was 14

No "unknown" type in Mac IE.

typeof window.location.replace
IE:mac 5.1 -> 'unknown'
IE:mac 5.2 -> 'unknown'

 

[David Mark]

David Mark wrote:
kangax wrote:
Conrad Lender wrote:

[...]

compatibility issues at all.  I can't see a better solution.  I've
been sold ever since 2001 (approx.) when it fixed the most mysterious
Mac IE bug I'd ever seen.  Sure enough, it was an "unknown" type.
I'm can't prove it was not, but I bet you are wrong on that.
Are you kidding?  

Not kidding.

It was an "unknown" type.  That's a fact.  And it

So you had an object where:-

typeof obj == "unknown"

was true in Mac IE. I have not seen that and I'm calling you on that. I
think you are mistaken. Please post an example.

You've been called out on that and no reply.

Pfft. I'm a little busy. Replies to your posts are on the back
burner these days.

No "unknown" type in Mac IE.

You don't have a clue.

[...]

Ah, you said:

| Gecko's document.all is an "undefined" type, despite its availability
| (clearly a cue from the Gecko developers to stay away from it.)

My reply is in response to that. Gecko developers were not cuing. They
were trying to make IE-only sites work.

Do you understand what a cue is?

And again, wrong on that one.

How can one guy keep saying I'm wrong on the same points over and over
and be wrong about it every time. Told about it every time, etc.
It's getting old. It is you that goes MIA every time you can't
answer. Keep your shit real, my brother.

[snip]

 

[Garrett Smith]

Garrett Smith wrote:

[...]

typeof window.location.replace
IE:mac 5.1 -> 'unknown'
IE:mac 5.2 -> 'unknown'

Thanks, Eric.

 

[David Mark]

David Mark wrote:
kangax wrote:
Conrad Lender wrote:
[...]

[...]

compatibility issues at all.  I can't see a better solution.  I've
been sold ever since 2001 (approx.) when it fixed the most mysterious
Mac IE bug I'd ever seen.  Sure enough, it was an "unknown" type.
I'm can't prove it was not, but I bet you are wrong on that.

Are you kidding?  

Not kidding.

It was an "unknown" type.  That's a fact.  And it

behaved just as the "unknown" types do in Windows (blows up on type
conversion, among other things.)

So you had an object where:-

typeof obj == "unknown"

was true in Mac IE. I have not seen that and I'm calling you on that. I
think you are mistaken. Please post an example.

I am so fucking tired of hearing what you haven't seen. Have you seen
it now? Good!

Ah, you said:

| Gecko's document.all is an "undefined" type, despite its availability
| (clearly a cue from the Gecko developers to stay away from it.)

My reply is in response to that. Gecko developers were not cuing. They
were trying to make IE-only sites work.

And do you understand that is a cue? Also, your interpretation of
their motivations is irrelevant. The fact is, the typeof operator
wins again.

Are you British?

No. What if I was?

I wanted to ask: Is what I wrote what you meant? Did you mean: If
isHostMethod(document, "getElementById"); returns true, then you can be
sure that isHostMethod is a host method.

?

I'll echo that. I know isHostMethod is not a host method.

That is a true statement and I think that is what you meant but it is
not what you wrote. You wrote:

| If it passes - for example - gEBI, you can be quite sure it is a host
| method.

- not true, if taken literally. Does not make much sense to me.

We've had this discussion a hundred times now. You pass a *method*
name (e.g. gEBI), not any arbitrary string (e.g. offsetParent.) Go
back and read.

That is what isHostMethod does. It does nothing more.

Who are you talking to?

That is *also* the approach for using the |in| operator.

Not at all. The - in - operator tells you nothing and may be unsafe.

Both are valid approaches. Neither is infallible.

We've discussed this to death.

No argument there.

Then, for the love of God, drop it.

The first argument is a host

object.  Not an Object object or a string or whatever.  The second is
the name of a method.  Not a name of any other type of property.  I
think it is quite clear.  The name kind of says it all.

The method requires the developer to know that the second argument is
the name of a method.

Do you see a parallel to the approach using |in| ?

The benefit to |in| is that is inline and does not require stepping into
another line of code in another file.

So, IIUC, isHostMethod detects the presence of a property, and that it
is not a primitive value (it even has to call [[Get]] to do that). DidI
get that right?

Not even in the ballpark.  And I don't think you are really trying.

How did you come to that, or why do you say that? Can you respond more
specifically to what I wrote?

That is not what it does.  In fact, such a method would be completely
idiotic (see jQuery.)  And see above.

It would be well-intentioned, but could not work.

Oh, but it does.  Perhaps not in the way you would like, but it is the
only way in reality.

isHostMethod(document, "images");

returns true in all browsers.

But document.images is *not* callable in all browsers.

You are such a fucking loser. See isHostObjectProperty. RTFM. STFW
and if you still can't figure it out, FOAD. Does that sum it up? I'm
tired of you wasting time and confusing issues.

[snip]

 

[David Mark]

Garrett Smith wrote:
David Mark wrote:

[...]

typeof window.location.replace
IE:mac 5.1 -> 'unknown'
IE:mac 5.2 -> 'unknown'

Thanks, Eric.

You could have just taken my word for it. Of course, I wasn't even
talking about Mac IE 5, but a much older variety that you've likely
never seen. How many times are you going to put your foot in your
mouth like this? We aren't looking to fill the position vacated by
Matt Kruse.

Next time take a deep breath, do some research and *then* fly off the
handle (assuming you still think you are right.)

 

[Garrett Smith]

[...]

That is what isHostMethod does. It does nothing more.

Who are you talking to?

That is *also* the approach for using the |in| operator.

Not at all. The - in - operator tells you nothing and may be unsafe.

Both are valid approaches. Neither is infallible.

We've discussed this to death.

No argument there.

Then, for the love of God, drop it.

The problem is that you seem to be advocating isHostMethod as having
superior method-checking skills. Method isHostMethod does not
deductively check to see if a property is a method. It requires
presupposition, *just like in does*.

Method isHostMethod has a drawback. It is an extra method call. It is
marginally slower than a function call and takes up more space. The in
operator is the simpler choice and is a valid choice in many circumstances.


Not surprised you ignored that one.

Yep, still a benefit.

You are such a fucking loser. See isHostObjectProperty. RTFM. STFW
and if you still can't figure it out, FOAD. Does that sum it up? I'm
tired of you wasting time and confusing issues.

It does not sum it up. It shows us what an asshole you are, but you do
that all the time. Real professional.

It also shows that you missed the point of that example. In case it
wasn't clear to others: The point of document.images being reported as a
Host Method by isHostMethod shows that that method returns true for a
property that is not a method in Firefox, but is a method in other
browsers. Yes, document.images *is* callable in several browsers
including IE, Opera, Safari. This is nonstandard, but legal, and is a fact:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>callable images</title>
</head>
<body>
<img src="">
<script type="text/javascript">
function isHostMethod(object, property) {
var t = typeof object[property];
return t=='function' ||
(!!(t=='object' && object[property])) ||
t=='unknown';
}

document.write("isHostMethod(document, 'images'): ");
document.write(isHostMethod(document, "images"));
document.write("<br>typeof document.images(0): ");
try {
document.write(typeof document.images(0));
} catch(ex) {
document.write("<b>not callable<\/b>");
}
</script>
</body>
</html>

Opera, Safari, IE:
isHostMethod(document, 'images'): true
typeof document.images(0): object

Firefox:
isHostMethod(document, 'images'): true
typeof document.images(0): not callable

Nobody should try calling document.images. It is a non-standard API
decision by microsoft that has resulted in confusion and compatibility
among developers and other vendors.

In short, the method isHostMethod does not do what the method name
implies; does not return true iff 1) the base object is a host object
and 2) the property is callable). That was the point of the
document.images example

Such long explanations are time consuming.

A better summary would be:-

The typeof operator is widely implemented. When used on host objects the
result is implementation-dependent. For callable host objects, the
resutl is usually "object", "function", or "unknown", depending on the
implementation. The wrapper |isHostMethod| checks to see if the return
value is one of those.

The |in| operator detects presence of a property in an object. It mostly
works on host objects by returning true of the object contains the
property.

Both appraoches, |in| or |typeof| require the developer to make a
presupposition of an property being callable-if-present.

Neither approach will determine if the object is callable.

The |in| operator is a more recent addition to the language and is not
implemented in Mac IE, which also has "unknown" type.

The typeof operator has varied results, depending on the implementation
and the property. This is makes a typeof strategy more complicated, so
if this approach is used, it is generally better to wrap it in a
function that clearly describes the intent of the code. The name
isHostMethod fails on that count.


FOAD, huh. You seem to want everyone who you disagree with to die.

Garrett

 

[David Mark]

David Mark wrote:
David Mark wrote:
kangax wrote:
Conrad Lender wrote:

[...]

What you've stated in the above paragraph (the one I am directly
replying to) is that isHostMethod requires the developer to have a
presupposition about what the presence of an object property means about it.
YES.  
That is what isHostMethod does. It does nothing more.

Who are you talking to?

Not at all.  The - in - operator tells you nothing and may be unsafe.

Then, for the love of God, drop it.

The problem is that you seem to be advocating isHostMethod as having
superior method-checking skills. Method isHostMethod does not
deductively check to see if a property is a method. It requires
presupposition, *just like in does*.

STOP. That's where you are wrong. You haven't read my numerous
comments (or the documentation), so you don't understand the logic of
it and therefore your "arguments" are skewed. An argument is point-
counterpoint and requires understanding. When I say point A, you
should not respond with an unrelated point B. It only serves to waste
time and confuse issues.

[snip]

 

[Garrett Smith]

David Mark wrote:
David Mark wrote:
kangax wrote:
Conrad Lender wrote: [...]



What you've stated in the above paragraph (the one I am directly
replying to) is that isHostMethod requires the developer to have a
presupposition about what the presence of an object property means about it.
YES.
That is what isHostMethod does. It does nothing more.
Who are you talking to?
That is *also* the approach for using the |in| operator.
Not at all. The - in - operator tells you nothing and may be unsafe.
Both are valid approaches. Neither is infallible.
We've discussed this to death.
No argument there.
Then, for the love of God, drop it.

The problem is that you seem to be advocating isHostMethod as having
superior method-checking skills. Method isHostMethod does not
deductively check to see if a property is a method. It requires
presupposition, *just like in does*.

STOP. That's where you are wrong.

Sounds like a contradiction to what you wrote earlier:

I wrote:

| What you've stated in the above paragraph (the one I am directly
| replying to) is that isHostMethod requires the developer to have a
| presupposition about what the presence of an object property means
| about it.

And you replied:
| YES.

And, as I just stated, (the part where you said I am wrong):

| isHostMethod does not deductively check to see if a property is a
|method. It requires presupposition, *just like in does*.

Neither approach determines callability and both are faulty in some way.
Either (or both) can be used in valid strategies. Both have benefits and
drawbacks.

The |in| operator is a good and useful operator that made it into
EMCA-262r3 (1999).

A strategy using |in| on host objects can mostly work (though not in Mac
IE). It is shorter, simpler, and faster than using an isHostMethod.

Garrett

 

[David Mark]

David Mark wrote:
David Mark wrote:
David Mark wrote:
kangax wrote:
Conrad Lender wrote:
[...]
What you've stated in the above paragraph (the one I am directly
replying to) is that isHostMethod requires the developer to have a
presupposition about what the presence of an object property meansabout it.
YES.  
That is what isHostMethod does. It does nothing more.
Who are you talking to?
That is *also* the approach for using the |in| operator.
Not at all.  The - in - operator tells you nothing and may be unsafe.
Both are valid approaches. Neither is infallible.
We've discussed this to death.
No argument there.
Then, for the love of God, drop it.
The problem is that you seem to be advocating isHostMethod as having
superior method-checking skills. Method isHostMethod does not
deductively check to see if a property is a method. It requires
presupposition, *just like in does*.

STOP.  That's where you are wrong.  

Sounds like a contradiction to what you wrote earlier:

Of course it does. Do you not see how that is a problem? Get your
hearing checked.

[snip\

 

[SteveYoungTbird]

David Mark wrote:
kangax wrote:
Conrad Lender wrote:
[...] [...]

compatibility issues at all. I can't see a better solution. I've
been sold ever since 2001 (approx.) when it fixed the most mysterious
Mac IE bug I'd ever seen. Sure enough, it was an "unknown" type.
I'm can't prove it was not, but I bet you are wrong on that.
Are you kidding?

Not kidding.

It was an "unknown" type. That's a fact. And it

behaved just as the "unknown" types do in Windows (blows up on type
conversion, among other things.)

So you had an object where:-

typeof obj == "unknown"

was true in Mac IE. I have not seen that and I'm calling you on that. I
think you are mistaken. Please post an example.

I am so fucking tired of hearing what you haven't seen. Have you seen
it now? Good!

Ah, you said:

| Gecko's document.all is an "undefined" type, despite its availability
| (clearly a cue from the Gecko developers to stay away from it.)

My reply is in response to that. Gecko developers were not cuing. They
were trying to make IE-only sites work.

And do you understand that is a cue? Also, your interpretation of
their motivations is irrelevant. The fact is, the typeof operator
wins again.

Are you British?

No. What if I was?

That's not even a possibility. You are far too uncouth.

 

[David Mark]

David Mark wrote:
David Mark wrote:
kangax wrote:
Conrad Lender wrote:
[...]
[...]
compatibility issues at all.  I can't see a better solution.  I've
been sold ever since 2001 (approx.) when it fixed the most mysterious
Mac IE bug I'd ever seen.  Sure enough, it was an "unknown" type.
I'm can't prove it was not, but I bet you are wrong on that.
Are you kidding?  
Not kidding.
It was an "unknown" type.  That's a fact.  And it
behaved just as the "unknown" types do in Windows (blows up on type
conversion, among other things.)
So you had an object where:-
typeof obj == "unknown"
was true in Mac IE. I have not seen that and I'm calling you on that. I
think you are mistaken. Please post an example.

I am so fucking tired of hearing what you haven't seen.  Have you seen
it now?  Good!

And do you understand that is a cue?  Also, your interpretation of
their motivations is irrelevant.  The fact is, the typeof operator
wins again.

No.  What if I was?

That's not even a possibility. You are far too uncouth.

If you are British, you are giving the country a bad name. Well, two
names.

 

[David Mark]

David Mark wrote:
David Mark wrote:
David Mark wrote:
kangax wrote:
Conrad Lender wrote:
[...]
What you've stated in the above paragraph (the one I am directly
replying to) is that isHostMethod requires the developer to have a
presupposition about what the presence of an object property meansabout it.
YES.  
That is what isHostMethod does. It does nothing more.
Who are you talking to?
That is *also* the approach for using the |in| operator.
Not at all.  The - in - operator tells you nothing and may be unsafe.
Both are valid approaches. Neither is infallible.
We've discussed this to death.
No argument there.
Then, for the love of God, drop it.
The problem is that you seem to be advocating isHostMethod as having
superior method-checking skills. Method isHostMethod does not
deductively check to see if a property is a method. It requires
presupposition, *just like in does*.

STOP.  That's where you are wrong.  

Sounds like a contradiction to what you wrote earlier:

I wrote:

| What you've stated in the above paragraph (the one I am directly
| replying to) is that isHostMethod requires the developer to have a
| presupposition about what the presence of an object property means
| about it.

And you replied:
| YES.

And, as I just stated, (the part where you said I am wrong):

| isHostMethod does not deductively check to see if a property is a
|method. It requires presupposition, *just like in does*.

Neither approach determines callability and both are faulty in some way.

As you see it. And, of course, there's the logic you don't seem to
understand. Read those one-liners (two maybe) again. They are not
the same as testing for the existence of a property.

Either (or both) can be used in valid strategies. Both have benefits and
drawbacks.

The |in| operator is a good and useful operator that made it into
EMCA-262r3 (1999).

Thanks for that.

A strategy using |in| on host objects can mostly work (though not in Mac
IE). It is shorter, simpler, and faster than using an isHostMethod.

You left out "far less effective."

Shorter and simpler don't enter into it. Again, are you kidding? And
faster sure, but not enough to matter. Basically, you just want to
argue, despite the fact that you have no argument.

 

[Garrett Smith]

David Mark wrote:
David Mark wrote:
David Mark wrote:
kangax wrote:
Conrad Lender wrote:
[...]

[...]

Neither approach determines callability and both are faulty in some way.

As you see it.

You can't seem to see anything other than the solution you have married
yourself to.

And, of course, there's the logic you don't seem to

understand. Read those one-liners (two maybe) again. They are not
the same as testing for the existence of a property.

They accomplish analagous results. The document.images collection is
*not* callable in Firefox, yet isHostMethod says it is.

You left out "far less effective."

Less effective at *what*?

Determining callability? Not that. Less effective at determining if the
base object is actually an object? Certainly not that, in fact the
opposite is true!

Shorter and simpler don't enter into it. Again, are you kidding? And
faster sure, but not enough to matter. Basically, you just want to
argue, despite the fact that you have no argument.

No, I provided a summary that |in| is a viable alternative to the
|isHostMethod|, that it is shorter and faster.

typeof checks fails fail to detect the item() method in IE. Not a
problem, if item is not used. It crashes under Safari 2 with NodeList.
that is a more serious problem.

|in| fails with false positive on document.styleSheets collection and
positive for things that are "hidden", which should never be a problem
(no reason to want to do that).

|in| works.

Garrett

 

[Thomas 'PointedEars' Lahn]

They accomplish analagous results. The document.images collection is
*not* callable in Firefox, yet isHostMethod says it is.

So there is a false positive, but it is a false positive that is caused by a
wrong premise of the caller. `document.images' is not supposed to be
subject to this feature test as it does not need to be called, and so its
callability is not an issue.

In contrast, the `in' operation makes exactly *no* statement about the
callability of the subject, in the best case it can only state its existence
(that is, either the object has this property or it is inherited through the
prototype chain). And it does that in a more error-prone and less
compatible way (cf. ES3F, sections 11.4.3 and 11.8.7, and the ECMAScript
Support Matrix).


PointedEars

 

[VK]

And, of course, there's the logic you don't seem to

So there is a false positive, but it is a false positive that is caused by a
wrong premise of the caller.  `document.images' is not supposed to be
subject to this feature test as it does not need to be called, and so its
callability is not an issue.

In contrast, the `in' operation makes exactly *no* statement about the
callability of the subject, in the best case it can only state its existence
(that is, either the object has this property or it is inherited through the
prototype chain).  And it does that in a more error-prone and less
compatible way (cf. ES3F, sections 11.4.3 and 11.8.7, and the ECMAScript
Support Matrix).

No one of posters raised the real problem of practical DOM
programming. It is not enough to know if a property is presented. Even
checking if the property is callable (acts as a method) doesn't do
much good. The most important is to know what and how this property/
method does in this particular UA (User Agent). A bit outdated yet
still actual for some intranet environments example:
document.createElement in IE6

window.alert('createElement' in document); // true
window.alert(typeof document.createElement); // 'object'
// but
window.alert(''.concat(document.createElement).indexOf('function')!
=-1); // true
// so a method

And what good of it unless I know that it is IE6? Because in IE6 it
will lead to a runtime error as soon as will try to create an INPUT
element. For IE6 I need to use
document.createElement('<INPUT TYPE="TEXT">') syntax which obviously
is not acceptable for say Firefox.

This is why we need to know the exact UA type and version our script
is running and there is no alternatives to that. The alternatives
appears for how do we detect the type and the version: either by
studying UserAgent string or by checking some properties of the host
object which are known in advance to be specific in their presence or
absence for a specific UA. The common modern trend is to use property
sniffing rather then UserAgent sniffing.

 

[Thomas 'PointedEars' Lahn]

And, of course, there's the logic you don't seem to
understand. Read those one-liners (two maybe) again. They are not
the same as testing for the existence of a property.
[`in' and `isHostMethod'] >>> accomplish analagous results. The document.images collection is
*not* callable in Firefox, yet isHostMethod says it is.

So there is a false positive, but it is a false positive that is caused by a
wrong premise of the caller. `document.images' is not supposed to be
subject to this feature test as it does not need to be called, and so its
callability is not an issue.

In contrast, the `in' operation makes exactly *no* statement about the
callability of the subject, in the best case it can only state its existence
(that is, either the object has this property or it is inherited through the
prototype chain). And it does that in a more error-prone and less
compatible way (cf. ES3F, sections 11.4.3 and 11.8.7, and the ECMAScript
Support Matrix).

No one of posters raised the real problem of practical DOM
programming. It is not enough to know if a property is presented. Even
checking if the property is callable (acts as a method) doesn't do
much good. The most important is to know what and how this property/
method does in this particular UA (User Agent).

The method is supposed to do what its name indicates.

A bit outdated yet still actual for some intranet environments example:
document.createElement in IE6

window.alert('createElement' in document); // true
window.alert(typeof document.createElement); // 'object'
// but
window.alert(''.concat(document.createElement).indexOf('function')!
=-1); // true
// so a method

Yes, we know that. Which is why methods determining the likelihood of
callability also test for "object" (and "unknown").

And what good of it unless I know that it is IE6? Because in IE6 it
will lead to a runtime error as soon as will try to create an INPUT
element. For IE6 I need to use
document.createElement('<INPUT TYPE="TEXT">') syntax which obviously
is not acceptable for say Firefox.

And not necessary for IE 6 at all.

This is why we need to know the exact UA type and version our script
is running and there is no alternatives to that. [...]

It is the same in all MSHTML 4+ based UAs, though, which renders your
argumentation utter nonsense if there was not sufficient evidence already
that you don't know what you are talking about.

Do not feed this troll. (Search the archives about it instead.)


PointedEars

 

[VK]

This is why we need to know the exact UA type and version our script
is running and there is no alternatives to that. [...]

It is the same in all MSHTML 4+ based UAs, though, which renders your
argumentation utter nonsense if there was not sufficient evidence already
that you don't know what you are talking about.

I do repeat my question: IF a host property is found AND it is checked
that it can be used as a method (is callable) THEN it must be the
method safe to call in the way and with the results exactly as
described by ? at ? (not sure what place to suggest but obviously it
has to be a single one).
Is this the story you are trying to sell or did I miss something?