opacity

[Peter Michaux]

I simply check to see if the element to be returned actually has the
appropriate id.

Ahh, ok. I thought you might be doing an elaborate DOM walk to find
the element that really has the correct id. This would have saved me
from a problem in a mashup that burned about an hour of my time last
week. In fact I think this would be a good function to have because it
fixes a bug in recent browsers. You win

But we already broke that rule with the opacity function.

The rule was a result of that experience.

It wasn't
much extra effort and I think it was worth it to make that basic
function optionally work for IE4.

I think that the time to enabled opacity on IE4 was plenty. I had to
figure out about document.all.tags and document.all[] during page load
and after. I had all sorts of browsers fired up. This sort of testing
isn't free.

[snip]

For the most part I agree. In this case, I think the name vs. id
issue is sufficient to warrant a wrapper for gEBI.

I agree. I had never even thought about writing code to fix that
problem before. It is a good idea. That is a bug that can be fixed.

It isn't exactly the question for me. But I think we've already
answered it to some extent. When it is simple to include an
additional version of a function that enables IE4

This is a grey area with the "simple". I'm looking for a consistent
rule for what to include. If a bit of code in the repository happens
to work on IE4 great but if not that is ok with me.

and somebody is
willing to write it, then it makes sense to include it. Most
applications won't need it, but why not have it available for those
that do?

I suppose it comes down to the fact that I'll probably have to write
the documentation, tests and almost certainly maintain it. These are
big time commitments. I'm not interested for IE4 having enhanced
JavaScript pages. Just HTML is fine.

Those who don't use the alternate versions of getAnElement, etc. won't
incur the extra download time. Other than that one and the gEBI
wrapper, I don't have any additional functions that warrant
alternative IE4-friendly versions. My gEBTN wrapper fixes a problem
with IE5.x as well. And other than that, I can't think of anything
else I've written that specifically addresses pre-IE6 issues.

Ok! I see a solution. So you need only two functions to help you
support IE4 at the level that satisfies you (but perhaps not someone
else). If the gEBID wrapper is included in the library to fix the IE5+
bug then there is only one issue for you: getAnElement.

I never intended that the repository would have all the multiple
implementations possible. The repository should have the ones that are
commonly used. A developer using the repository may have extenuating
circumstances that require an implementation not suitable to whatever
the guidelines are for the repository. The developer is free to
maintain an implementation of a particular function outside the
repository and include it in his build process. This is what I
envisioned from the beginning.

So if you were going to use the repository you would just maintain
your own getAnElement. That is just one function outside the
repository. How does that sound?

I kind of mucked up that explanation. You would need to maintain your
own gEBID and getAnElement to have your level of support for IE4. The
logic that a developer with uncommon requirements maintains his own
implementations was the point.

Peter

 

[David Mark]

Ahh, ok. I thought you might be doing an elaborate DOM walk to find
the element that really has the correct id. This would have saved me

That would be going too far.

from a problem in a mashup that burned about an hour of my time last
week. In fact I think this would be a good function to have because it
fixes a bug in recent browsers. You win

Okay, let me know when you want to put the wrappers in for gEBI and
gEBTN. Once those are in, we can add getBodyElement and
getHeadElement. Then the basic foundation for feature detection will
be in place. Speaking of that, I finally figured out what Thomas
Lahn was saying about error-prone method checking of host objects. I
deprecated my "isFeature" function in favor of:

var reFeaturedMethod = new RegExp('^function|object$', 'i');

isFeaturedMethod = api.isFeaturedMethod = function(o, m) {
var t = typeof(o[m]);
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
};

Ex.

if (this.external) { alert(isFeaturedMethod(this.external,
'addFavorite')); }
alert(isFeaturedMethod(this.document, 'all'));

This is similar to Thomas' oft-mentioned isFeatureType function, but
is slightly in improved in that it does the truthy test internal and
covers ActiveX methods. Point to PointedEars. On the downside, the
fact that I am agreeing with him may signal the end of the world.

The rule was a result of that experience.

I agree.

I think that the time to enabled opacity on IE4 was plenty. I had to
figure out about document.all.tags and document.all[] during page load
and after. I had all sorts of browsers fired up. This sort of testing
isn't free.

But it enabled far more possibilities than just getOpacity.
Especially in feature testing, where retrieving the html element (or
any element in some cases) is typically step one.

[snip]

For the most part I agree. In this case, I think the name vs. id
issue is sufficient to warrant a wrapper for gEBI.

I agree. I had never even thought about writing code to fix that
problem before. It is a good idea. That is a bug that can be fixed.

It isn't exactly the question for me. But I think we've already
answered it to some extent. When it is simple to include an
additional version of a function that enables IE4

This is a grey area with the "simple". I'm looking for a consistent
rule for what to include. If a bit of code in the repository happens
to work on IE4 great but if not that is ok with me.

I agree. Most of what I write degrades to plain HTML in IE4.

I suppose it comes down to the fact that I'll probably have to write
the documentation, tests and almost certainly maintain it. These are
big time commitments. I'm not interested for IE4 having enhanced
JavaScript pages. Just HTML is fine.

Right. But at least it will be able to find documents and set their
opacity (for starters.) It will also be able to show, hide and toggle
elements, remove them from the layout, change their display style,
etc. As a matter of fact, all of my special effects should work in
IE4. A few of them were originally written back in the IE4 days.

Ok! I see a solution. So you need only two functions to help you
support IE4 at the level that satisfies you (but perhaps not someone
else). If the gEBID wrapper is included in the library to fix the IE5+

No. The gEBTN wrapper fixes an IE5 bug.

bug then there is only one issue for you: getAnElement.

Why is that one an issue? We just need to make sure there is also a
getHTMLElement.

I never intended that the repository would have all the multiple
implementations possible. The repository should have the ones that are
commonly used. A developer using the repository may have extenuating
circumstances that require an implementation not suitable to whatever
the guidelines are for the repository. The developer is free to
maintain an implementation of a particular function outside the
repository and include it in his build process. This is what I
envisioned from the beginning.

So if you were going to use the repository you would just maintain
your own getAnElement. That is just one function outside the
repository. How does that sound?

I don't understand why there is an issue at all. We know gEBTN is
broken in IE5, so that needs a wrapper. It sounds like you are now in
favor of a gEBI wrapper and we can break mine up into two (one of
which will support IE4, just like getAnElement/getHTMLElement.) If
you mean that you don't want to include the backward compatible
versions of these in the repository, that makes no difference to me.
My main point has always been to avoid calling things like gEBI in the
higher-level functions. That way anybody can override the stock
wrapper with whatever they need.

 

[David Mark]

I kind of mucked up that explanation. You would need to maintain your

own gEBID and getAnElement to have your level of support for IE4. The
logic that a developer with uncommon requirements maintains his own
implementations was the point.

Sounds good to me.

 

[Peter Michaux]

Ahh, ok. I thought you might be doing an elaborate DOM walk to find
the element that really has the correct id. This would have saved me

That would be going too far.

from a problem in a mashup that burned about an hour of my time last
week. In fact I think this would be a good function to have because it
fixes a bug in recent browsers. You win

Okay, let me know when you want to put the wrappers in for gEBI and
gEBTN. Once those are in, we can add getBodyElement and
getHeadElement. Then the basic foundation for feature detection will
be in place.

Speaking of that, I finally figured out what Thomas
Lahn was saying about error-prone method checking of host objects. I
deprecated my "isFeature" function in favor of:

var reFeaturedMethod = new RegExp('^function|object$', 'i');

isFeaturedMethod = api.isFeaturedMethod = function(o, m) {
var t = typeof(o[m]);
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');

};

Ex.

if (this.external) { alert(isFeaturedMethod(this.external,
'addFavorite')); }
alert(isFeaturedMethod(this.document, 'all'));

This is similar to Thomas' oft-mentioned isFeatureType function, but
is slightly in improved in that it does the truthy test internal and
covers ActiveX methods. Point to PointedEars. On the downside, the
fact that I am agreeing with him

It's contagious.

may signal the end of the world.







I agree.

You must be getting blurry eyed too. You are agreeing with yourself
now! ;-)


[snip]

No. The gEBTN wrapper fixes an IE5 bug.

That is the '*' bug but I was referring to the name/id bug.

Why is that one an issue? We just need to make sure there is also a
getHTMLElement.





I don't understand why there is an issue at all. We know gEBTN is
broken in IE5, so that needs a wrapper.
Yes.

It sounds like you are now in
favor of a gEBI wrapper and we can break mine up into two (one of
which will support IE4, just like getAnElement/getHTMLElement.)
Yes.

If
you mean that you don't want to include the backward compatible
versions of these in the repository, that makes no difference to me.

I do not want to include them (at least for now).

My main point has always been to avoid calling things like gEBI in the
higher-level functions.

I just really don't want things like Function.prototype.apply to
become "things like gEBI"....wrapper hell.

That way anybody can override the stock
wrapper with whatever they need.

Yes.

I think we are finished. It has been very informative. Thanks. No
doubt this is some of the most heavily scrutinized code around.

If you want to post a new thread for gEBI and a separate thread for
gEBTN please do. (Please put the project name in parens in the
subject)

 

[David Mark]

That would be going too far.

Okay, let me know when you want to put the wrappers in for gEBI and
gEBTN. Once those are in, we can add getBodyElement and
getHeadElement. Then the basic foundation for feature detection will
be in place.

Speaking of that, I finally figured out what Thomas
Lahn was saying about error-prone method checking of host objects. I
deprecated my "isFeature" function in favor of:

var reFeaturedMethod = new RegExp('^function|object$', 'i');

isFeaturedMethod = api.isFeaturedMethod = function(o, m) {
var t = typeof(o[m]);
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');

};

Ex.

if (this.external) { alert(isFeaturedMethod(this.external,
'addFavorite')); }
alert(isFeaturedMethod(this.document, 'all'));

This is similar to Thomas' oft-mentioned isFeatureType function, but
is slightly in improved in that it does the truthy test internal and
covers ActiveX methods. Point to PointedEars. On the downside, the
fact that I am agreeing with him

It's contagious.

I hope not.

This is how it starts. Next thing you know, people will start
agreeing with VK. I think one of Nostradamus' quatrains referenced
such events as a prelude to the apocalypse.

You must be getting blurry eyed too. You are agreeing with yourself
now! ;-)

I always agree with myself.

[snip]

No. The gEBTN wrapper fixes an IE5 bug.

That is the '*' bug but I was referring to the name/id bug.

Right.

Why is that one an issue? We just need to make sure there is also a
getHTMLElement.

I don't understand why there is an issue at all. We know gEBTN is
broken in IE5, so that needs a wrapper.
Yes.

It sounds like you are now in
favor of a gEBI wrapper and we can break mine up into two (one of
which will support IE4, just like getAnElement/getHTMLElement.)
Yes.

If
you mean that you don't want to include the backward compatible
versions of these in the repository, that makes no difference to me.

I do not want to include them (at least for now).

As long as there are wrappers to override for cases of specific need,
then everyone should be happy.

I just really don't want things like Function.prototype.apply to
become "things like gEBI"....wrapper hell.

Definitely not. Though I am glad to see you are feature testing apply
and call. I had wondered recently if doing so was overly paranoid,
but then I found out that IE5.0 doesn't quite support all of
Javascript 1.2.

Yes.

I think we are finished. It has been very informative. Thanks. No
doubt this is some of the most heavily scrutinized code around.

Which is good as everything else will sit on top of it. We don't want
to duplicate the (currently) popular libraries by building towers on a
swampy foundation.

If you want to post a new thread for gEBI and a separate thread for
gEBTN please do. (Please put the project name in parens in the
subject)

I should have some time for that tomorrow. I've had enough JavaScript
for today.

I should note that there are actually two wrappers for gEBTN. They
were posted here about a month ago. One is for document nodes and the
other for elements. I'll explain why when I post them tomorrow.

 

[Thomas 'PointedEars' Lahn]

Speaking of that, I finally figured out what Thomas Lahn was saying about
error-prone method checking of host objects. I deprecated my "isFeature"
function in favor of:

var reFeaturedMethod = new RegExp('^function|object$', 'i');

isFeaturedMethod = api.isFeaturedMethod = function(o, m) { var t =
typeof(o[m]); return !!((reFeaturedMethod.test(t) && o[m]) || t ==
'unknown'); };

Ex.

if (this.external) { alert(isFeaturedMethod(this.external,
'addFavorite')); } alert(isFeaturedMethod(this.document, 'all'));

This is similar to Thomas' oft-mentioned isFeatureType function, but is
slightly in improved in that it does the truthy test internal and covers
ActiveX methods.

No, it does not. You have still not understood that the problem with the
encapsulation of the testing algorithm is the early evaluation of the
property value. `this.external' is such one; `typeof this.external', which
really should be `typeof window.external', is not. The bottom line is that
there is a part of a reliable feature test that can not be encapsulated in a
method.

Point to PointedEars. On the downside, the fact that I am agreeing with
him may signal the end of the world.

You are much farther from the truth than you think you are.


PointedEars

 

[Thomas 'PointedEars' Lahn]

I hope not.


This is how it starts. Next thing you know, people will start
agreeing with VK. I think one of Nostradamus' quatrains referenced
such events as a prelude to the apocalypse.

Generally, understanding will be helped greatly by considering the argument
before the name. That is where many people fail to make the distinction.


PointedEars

 

[David Mark]

Speaking of that, I finally figured out what Thomas Lahn was saying about
error-prone method checking of host objects. I deprecated my "isFeature"
function in favor of:

var reFeaturedMethod = new RegExp('^function|object$', 'i');

isFeaturedMethod = api.isFeaturedMethod = function(o, m) { var t =
typeof(o[m]); return !!((reFeaturedMethod.test(t) && o[m]) || t ==
'unknown'); };

Ex.

if (this.external) { alert(isFeaturedMethod(this.external,
'addFavorite')); } alert(isFeaturedMethod(this.document, 'all'));

This is similar to Thomas' oft-mentioned isFeatureType function, but is
slightly in improved in that it does the truthy test internal and covers
ActiveX methods.

No, it does not. You have still not understood that the problem with the
encapsulation of the testing algorithm is the early evaluation of the
property value. `this.external' is such one; `typeof this.external', which

I understand perfectly. A slightly improved version would add a
similar function to test the object that exposes the method:

isRealObjectProperty = api.isRealObjectProperty = function(o, p) {
return !!(typeof(o[p]) == 'object' && o[p]);
};

if (isRealObjectProperty(this, 'external'))
{ alert(isFeaturedMethod(this.external, 'addFavorite')); }

Granted, this one would fail if the external object were an ActiveX
method (which it isn't.) I really should have used a simpler
example. See below.

really should be `typeof window.external', is not. The bottom line is that

No it shouldn't. If there is no global window property, then that
will error. Talk about error-prone.

there is a part of a reliable feature test that can not be encapsulated in a
method.

I don't agree. What's wrong with this:

alert(isFeaturedMethod(this, 'addEventListener'));

Or as you would put it:

alert(isFeaturedMethod(this.window, 'addEventListener'));

Of course, considering your position, you would consider that error-
prone as window is a host object.

Looking at the function:

var reFeaturedMethod = new RegExp('^function|object$', 'i');

isFeaturedMethod = function(o, m) {
var t = typeof(o[m]);
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
};

The first parameter is the global object (window object), the second
is a string. No possibility of an evaluation error there. The first
line assigns the type of a method of a known object (a string) to a
variable. No issue there. The second line performs a test on a
string and if it indicates that o[m] is an object or method, then it
is evaluated to assure it isn't null. If the conjunction is false,
then a final string comparison adds support for ActiveX methods, which
I tested with the first posted example. No problem.

You are much farther from the truth than you think you are.

I sure hope so.

 

[Thomas 'PointedEars' Lahn]

Speaking of that, I finally figured out what Thomas Lahn was saying about
error-prone method checking of host objects. I deprecated my "isFeature"
function in favor of:
var reFeaturedMethod = new RegExp('^function|object$', 'i');
isFeaturedMethod = api.isFeaturedMethod = function(o, m) { var t =
typeof(o[m]); return !!((reFeaturedMethod.test(t) && o[m]) || t ==
'unknown'); };
Ex.
if (this.external) { alert(isFeaturedMethod(this.external,
'addFavorite')); } alert(isFeaturedMethod(this.document, 'all'));
This is similar to Thomas' oft-mentioned isFeatureType function, but is
slightly in improved in that it does the truthy test internal and covers
ActiveX methods.

No, it does not. You have still not understood that the problem with the
encapsulation of the testing algorithm is the early evaluation of the
property value. `this.external' is such one; `typeof this.external', which

I understand perfectly. A slightly improved version would add a
similar function to test the object that exposes the method:

isRealObjectProperty = api.isRealObjectProperty = function(o, p) {
return !!(typeof(o[p]) == 'object' && o[p]);
};

if (isRealObjectProperty(this, 'external'))
{ alert(isFeaturedMethod(this.external, 'addFavorite')); }

I don't see the improvement of this over

if (typeof this.external != "undefined")
{
// ...
}

You are assuming that a value needs to yield typeof "object" in order to
allow property access; however, that is not the case.

Granted, this one would fail if the external object were an ActiveX
method (which it isn't.)

It will fail in a great many other cases, too.

No it shouldn't. If there is no global window property, then that
will error. Talk about error-prone.

Correct. It should be

typeof window != "undefined"
&& typeof window.external ...

But you miss the point.

I don't agree. What's wrong with this:

alert(isFeaturedMethod(this, 'addEventListener'));

In the case of `this' that would be OK. However, we are talking about the
general use of a feature test.

Or as you would put it:

alert(isFeaturedMethod(this.window, 'addEventListener'));

I would most certainly not perform this feature test.

Of course, considering your position, you would consider that error-
prone as window is a host object.

Looking at the function:

var reFeaturedMethod = new RegExp('^function|object$', 'i');

isFeaturedMethod = function(o, m) {
var t = typeof(o[m]);
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
};

The first parameter is the global object (window object),

The Global Object is not necessarily the object that the host-defined
`window' property of Global Object refers to. Until you got that it does
not make sense to continue discussing with you about proper feature tests.

[...]
I tested with the first posted example. No problem.

You have tested with a subset of user agents and leap to the conclusion that
there can never be a problem.


PointedEars

 

[David Mark]

David Mark wrote:
Speaking of that, I finally figured out what Thomas Lahn was saying about
error-prone method checking of host objects. I deprecated my "isFeature"
function in favor of:
var reFeaturedMethod = new RegExp('^function|object$', 'i');
isFeaturedMethod = api.isFeaturedMethod = function(o, m) { var t =
typeof(o[m]); return !!((reFeaturedMethod.test(t) && o[m]) || t ==
'unknown'); };
Ex.
if (this.external) { alert(isFeaturedMethod(this.external,
'addFavorite')); } alert(isFeaturedMethod(this.document, 'all'));
This is similar to Thomas' oft-mentioned isFeatureType function, but is
slightly in improved in that it does the truthy test internal and covers
ActiveX methods.
No, it does not. You have still not understood that the problem with the
encapsulation of the testing algorithm is the early evaluation of the
property value. `this.external' is such one; `typeof this.external', which

I understand perfectly. A slightly improved version would add a
similar function to test the object that exposes the method:

isRealObjectProperty = api.isRealObjectProperty = function(o, p) {
return !!(typeof(o[p]) == 'object' && o[p]);
};

if (isRealObjectProperty(this, 'external'))
{ alert(isFeaturedMethod(this.external, 'addFavorite')); }

I don't see the improvement of this over

if (typeof this.external != "undefined")
{
// ...
}

Obviously, it takes care of the case where this.external === null.

You are assuming that a value needs to yield typeof "object" in order to
allow property access; however, that is not the case.

What a ridiculous assumption that would be in an ECMAScript
implementation. However, I do rightly assume that a null object won't
allow property access.

It will fail in a great many other cases, too.

Yes. Any circumstance where a host environment's implementation of
external throws an exception on [[get]]. Methods of ActiveX objects
are the most common example.

Correct. It should be

typeof window != "undefined"
&& typeof window.external ...

Which is basically what my functions do.

But you miss the point.

Perhaps. It is often difficult to tell what your point is.

In the case of `this' that would be OK. However, we are talking about the
general use of a feature test.

Right. You have to know what you are doing when you call these
functions. See the above example with external.

I would most certainly not perform this feature test.

Right. If you were to use this.window (as opposed to just "this")
then you would need two calls like in the external example. And that
one would turn into three tests. I still say this is needless
redundancy.

Of course, considering your position, you would consider that error-
prone as window is a host object.

Looking at the function:

var reFeaturedMethod = new RegExp('^function|object$', 'i');

isFeaturedMethod = function(o, m) {
var t = typeof(o[m]);
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
};

The first parameter is the global object (window object),

The Global Object is not necessarily the object that the host-defined
`window' property of Global Object refers to. Until you got that it does
not make sense to continue discussing with you about proper feature tests.

You have just changed the subject. Never mind your insistence on
introducing redundant testing related to the window object. Your
original argument was that my functions couldn't encapsulate the check
for a non-null object. It appears you were mistaken.

[...]
I tested with the first posted example. No problem.

You have tested with a subset of user agents and leap to the conclusion that
there can never be a problem.

You have snipped out the context of that quote. It referred to the
testing of ActiveX methods. And I tested with virtually every version
of Windows IE, which is the only browser that exposes ActiveX
methods. If you think there is a problem related to the global/window
issue that you keep coming back to, that is another matter (and I
still disagree with you.)

 

[Thomas 'PointedEars' Lahn]

On Dec 7, 7:37 pm, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
David Mark wrote:
Speaking of that, I finally figured out what Thomas Lahn was saying about
error-prone method checking of host objects. I deprecated my "isFeature"
function in favor of:
var reFeaturedMethod = new RegExp('^function|object$', 'i');
isFeaturedMethod = api.isFeaturedMethod = function(o, m) { var t =
typeof(o[m]); return !!((reFeaturedMethod.test(t) && o[m]) || t ==
'unknown'); };
Ex.
if (this.external) { alert(isFeaturedMethod(this.external,
'addFavorite')); } alert(isFeaturedMethod(this.document, 'all'));
This is similar to Thomas' oft-mentioned isFeatureType function, but is
slightly in improved in that it does the truthy test internal and covers
ActiveX methods.
No, it does not. You have still not understood that the problem with the
encapsulation of the testing algorithm is the early evaluation of the
property value. `this.external' is such one; `typeof this.external', which
I understand perfectly. A slightly improved version would add a
similar function to test the object that exposes the method:
isRealObjectProperty = api.isRealObjectProperty = function(o, p) {
return !!(typeof(o[p]) == 'object' && o[p]);
};
if (isRealObjectProperty(this, 'external'))
{ alert(isFeaturedMethod(this.external, 'addFavorite')); }

I don't see the improvement of this over

if (typeof this.external != "undefined")
{
// ...
}

Obviously, it takes care of the case where this.external === null.

Or any other false-value. However, that is hardly sufficient.

You are assuming that a value needs to yield typeof "object" in order to
allow property access; however, that is not the case.

What a ridiculous assumption that would be in an ECMAScript
implementation. [...]

Exactly. Yet you are making it.

It will fail in a great many other cases, too.

Yes. Any circumstance where a host environment's implementation of
external throws an exception on [[get]]. Methods of ActiveX objects
are the most common example.

And any circumstance where a primitive value or native object different from
Object or Object objects are involved.

Which is basically what my functions do.

But they don't, and they can't. For `foo.bar' you would have to pass the
`foo' reference to them which, as it may be not qualified, may cause a
ReferenceError exception.

Perhaps. It is often difficult to tell what your point is.

My point is that you can not perform all feature testing with passing plain
values to a method.

I would most certainly not perform this feature test.

Right. If you were to use this.window (as opposed to just "this")
then you would need two calls like in the external example. [...]

No, I would not attempt to access the Global Object with `this' as this code
would be part of local code, probably a user-defined object's method, and I
would most certainly not call the addEventListener() method of DOM Level 2
on a proprietary host object.

Of course, considering your position, you would consider that error-
prone as window is a host object.
Looking at the function:
var reFeaturedMethod = new RegExp('^function|object$', 'i');
isFeaturedMethod = function(o, m) {
var t = typeof(o[m]);
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
};
The first parameter is the global object (window object),

The Global Object is not necessarily the object that the host-defined
`window' property of Global Object refers to. Until you got that it does
not make sense to continue discussing with you about proper feature tests.

You have just changed the subject. [...]

I have not. You have, by posting your misconception again.

[...]
I tested with the first posted example. No problem.

You have tested with a subset of user agents and leap to the conclusion that
there can never be a problem.

You have snipped out the context of that quote. It referred to the
testing of ActiveX methods. And I tested with virtually every version
of Windows IE, which is the only browser that exposes ActiveX
methods. [...]

Wrong.


PointedEars

 

[David Mark]

David Mark wrote:
On Dec 7, 7:37 pm, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
David Mark wrote:
Speaking of that, I finally figured out what Thomas Lahn was saying about
error-prone method checking of host objects. I deprecated my "isFeature"
function in favor of:
var reFeaturedMethod = new RegExp('^function|object$', 'i');
isFeaturedMethod = api.isFeaturedMethod = function(o, m) { var t =
typeof(o[m]); return !!((reFeaturedMethod.test(t) && o[m]) || t ==
'unknown'); };
Ex.
if (this.external) { alert(isFeaturedMethod(this.external,
'addFavorite')); } alert(isFeaturedMethod(this.document, 'all'));
This is similar to Thomas' oft-mentioned isFeatureType function, but is
slightly in improved in that it does the truthy test internal and covers
ActiveX methods.
No, it does not. You have still not understood that the problem with the
encapsulation of the testing algorithm is the early evaluation of the
property value. `this.external' is such one; `typeof this.external', which
I understand perfectly. A slightly improved version would add a
similar function to test the object that exposes the method:
isRealObjectProperty = api.isRealObjectProperty = function(o, p) {
return !!(typeof(o[p]) == 'object' && o[p]);
};
if (isRealObjectProperty(this, 'external'))
{ alert(isFeaturedMethod(this.external, 'addFavorite')); }
I don't see the improvement of this over
if (typeof this.external != "undefined")
{
// ...
}

Obviously, it takes care of the case where this.external === null.

Or any other false-value. However, that is hardly sufficient.

What a ridiculous assumption that would be in an ECMAScript
implementation. [...]

Exactly. Yet you are making it.

I certainly am not. And you snipped my explanation as to why.

Yes. Any circumstance where a host environment's implementation of
external throws an exception on [[get]]. Methods of ActiveX objects
are the most common example.

And any circumstance where a primitive value or native object different from
Object or Object objects are involved.

Which is basically what my functions do.

But they don't, and they can't. For `foo.bar' you would have to pass the
`foo' reference to them which, as it may be not qualified, may cause a
ReferenceError exception.

See my examples. They all start at the global object, passed as
"this."

My point is that you can not perform all feature testing with passing plain
values to a method.

I have no idea what that means.

Right. If you were to use this.window (as opposed to just "this")
then you would need two calls like in the external example. [...]

No, I would not attempt to access the Global Object with `this' as this code
would be part of local code, probably a user-defined object's method, and I

What code would be part of a user-defined object's method? You are
going off on a tangent. The examples I posted should be assumed to
run in the global context.

would most certainly not call the addEventListener() method of DOM Level 2
on a proprietary host object.

We all know about your stance on that. However, this example didn't
do that (it just detected that the method was featured.)

Of course, considering your position, you would consider that error-
prone as window is a host object.
Looking at the function:
var reFeaturedMethod = new RegExp('^function|object$', 'i');
isFeaturedMethod = function(o, m) {
var t = typeof(o[m]);
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
};
The first parameter is the global object (window object),
The Global Object is not necessarily the object that the host-defined
`window' property of Global Object refers to. Until you got that it does
not make sense to continue discussing with you about proper feature tests.

You have just changed the subject. [...]

I have not. You have, by posting your misconception again.

[...]
I tested with the first posted example. No problem.
You have tested with a subset of user agents and leap to the conclusion that
there can never be a problem.

You have snipped out the context of that quote. It referred to the
testing of ActiveX methods. And I tested with virtually every version
of Windows IE, which is the only browser that exposes ActiveX
methods. [...]

Wrong.

We're done here.

 

[Thomas 'PointedEars' Lahn]

On Dec 8, 6:01 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
David Mark wrote:
isRealObjectProperty = api.isRealObjectProperty = function(o, p) {
return !!(typeof(o[p]) == 'object' && o[p]);
};
if (isRealObjectProperty(this, 'external'))
{ alert(isFeaturedMethod(this.external, 'addFavorite')); }
[...]
You are assuming that a value needs to yield typeof "object" in order to
allow property access; however, that is not the case.
What a ridiculous assumption that would be in an ECMAScript
implementation. [...]

Exactly. Yet you are making it.

I certainly am not. And you snipped my explanation as to why.

You do, and there was no explanation of that. (How could you explain
something that is obviously ridiculous?)

See my examples. They all start at the global object, passed as
"this."

First, your examples are insufficient for proof of general applicability,
which is what should be targeted with such a method (else no method would be
required). Second, `this' does not always refer to the Global Object, so if
that is an argument you are trying to make here with that sentence, it is
not at all a solid one.

I have no idea what that means.

Although it does have meaning for people who know what they are doing.

Or as you would put it:
alert(isFeaturedMethod(this.window, 'addEventListener'));
I would most certainly not perform this feature test.
Right. If you were to use this.window (as opposed to just "this")
then you would need two calls like in the external example. [...]

No, I would not attempt to access the Global Object with `this' as this code
would be part of local code, probably a user-defined object's method, and I

What code would be part of a user-defined object's method?

The code to be feature-tested, of course.

You are going off on a tangent.

I am not.

The examples I posted should be assumed to run in the global context.

Which merely demonstrates your shortsightedness.

We all know about your stance on that. However, this example didn't
do that (it just detected that the method was featured.)

It does not make sense to test for a feature that is not used afterwards, so
yes, either you were about to call that method or you have a lot more to
learn than I thought.

[...]
I tested with the first posted example. No problem.
You have tested with a subset of user agents and leap to the conclusion that
there can never be a problem.
You have snipped out the context of that quote. It referred to the
testing of ActiveX methods. And I tested with virtually every version
of Windows IE, which is the only browser that exposes ActiveX
methods. [...]

Wrong.

We're done here.

Apparently *you* are done here, i.e. you refuse to think about it, and
so, inevitably, you will produce error-prone code. Code that cannot be
recommended to others at all in good faith.


Please trim your quotes as you can see in each and every posting of
mine (and other posters) and as described in the FAQ and FAQ Notes:

http://www.jibbering.com/faq/#FAQ2_3
http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1Trim


PointedEars

 

[Peter Michaux]

[snip]

And if you get typeof(o) == 'object', how does that tell you it is
callable?

If I get that result and *then* the value is not a false-value and I
am expecting the identifier to designate a host object's method, at
the least I can be pretty sure that it is callable.

That seems reasonable.

[snip]

 

[Peter Michaux]

On Dec 8, 6:01 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
[snip]

[...]
I tested with the first posted example. No problem.

You have tested with a subset of user agents and leap to the conclusion that
there can never be a problem.

You have snipped out the context of that quote. It referred to the
testing of ActiveX methods. And I tested with virtually every version
of Windows IE, which is the only browser that exposes ActiveX
methods. If you think there is a problem related to the global/window
issue that you keep coming back to, that is another matter (and I
still disagree with you.)

Were these IE browser versions all on the same install of windows? I
am getting more sceptical of this type of testing lately.
Unfortunately a solution costs real dollars :-S

 

[Peter Michaux]

[snip]

Which is basically what my functions do.

But they don't, and they can't. For `foo.bar' you would have to pass the
`foo' reference to them which, as it may be not qualified, may cause a
ReferenceError exception.

I've read some of David Mark's code lately. It seems that when he
calls one of his functions like isRealObjectProperty(o,p) or
isFeaturedMethod(o, m) he has already checked properly that the 'o'
argument is qualified. For example, from David's code

if (isRealObjectProperty(this, 'document')) {
doc = this.document;

// snip ...

if (isFeaturedMethod(doc, 'getElementById')) {
return function(id, docNode) {
return idCheck((docNode || doc).getElementById(id), id);
};
}

In the call to isFeaturedMethod there is no need to check the typeof
doc. It is already known from the isRealObjectProperty call. This
statement assumes that the isFeaturedMethod and isRealObjects work as
advertised.

I think David will never have the error that you are concerned about
when you write about unqualified references causing an error when the
call is made.

 

[Thomas 'PointedEars' Lahn]

[...] For example, from David's code

if (isRealObjectProperty(this, 'document')) {
doc = this.document;

// snip ...

if (isFeaturedMethod(doc, 'getElementById')) {
return function(id, docNode) {
return idCheck((docNode || doc).getElementById(id), id);
};
}

In the call to isFeaturedMethod there is no need to check the typeof
doc. It is already known from the isRealObjectProperty call. This
statement assumes that the isFeaturedMethod and isRealObjects work as
advertised.

I think David will never have the error that you are concerned about
when you write about unqualified references causing an error when the
call is made.

ACK. However, this will require at least one reference to be qualified, and
be it only a reference to the global object. With this approach, if you are
going to test e.g. whether or not the global encodeURIComponent() method is
supported, or if you have to fall back to escape() or even a dummy method,
you will have to write

var _global = this;

// local context only for the sake of the argument
function foo()
{
if (isFeaturedMethod(_global, 'encodeURIComponent'))
{
// ...
}
}

as opposed to

function foo()
{
if (typeof encodeURIComponent == "function")
{
// ...
}
}

Not only is one call more on the stack, there is also a dependency on
`_global'. Now consider a host object's method and the calls that would
be involved in testing it.


PointedEars

 

[Peter Michaux]

[...] For example, from David's code

if (isRealObjectProperty(this, 'document')) {
doc = this.document;

// snip ...

if (isFeaturedMethod(doc, 'getElementById')) {
return function(id, docNode) {
return idCheck((docNode || doc).getElementById(id), id);
};
}

In the call to isFeaturedMethod there is no need to check the typeof
doc. It is already known from the isRealObjectProperty call. This
statement assumes that the isFeaturedMethod and isRealObjects work as
advertised.

I think David will never have the error that you are concerned about
when you write about unqualified references causing an error when the
call is made.

ACK.

I don't know what this means. I rarely know what your abbreviations
mean.

However, this will require at least one reference to be qualified, and
be it only a reference to the global object.

That could be done with the following around all the code.

if (typeof this != 'unknown') {

}

With this approach, if you are
going to test e.g. whether or not the global encodeURIComponent() method is
supported, or if you have to fall back to escape() or even a dummy method,
you will have to write

var _global = this;

// local context only for the sake of the argument
function foo()
{
if (isFeaturedMethod(_global, 'encodeURIComponent'))
{
// ...
}
}

as opposed to

function foo()
{
if (typeof encodeURIComponent == "function")
{
// ...
}
}

Not only is one call more on the stack, there is also a dependency on
`_global'.

Yes yours is simpler and so if it is sufficient would be the sensible
choice.

Now consider a host object's method and the calls that would
be involved in testing it.

If you just mean there are many more calls to the testing functions
then I understand your point.

 

[David Mark]

On Dec 8, 6:01 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
[snip]

[...]
I tested with the first posted example. No problem.
You have tested with a subset of user agents and leap to the conclusion that
there can never be a problem.

You have snipped out the context of that quote. It referred to the
testing of ActiveX methods. And I tested with virtually every version
of Windows IE, which is the only browser that exposes ActiveX
methods. If you think there is a problem related to the global/window
issue that you keep coming back to, that is another matter (and I
still disagree with you.)

Were these IE browser versions all on the same install of windows? I
Yes.

am getting more sceptical of this type of testing lately.

There can be issues, like the DirectX opacity "library not registered"
snafu (which can safely be ignored unless you are worried about
developers' test machines.) I have the ActiveX feature testing on
Win98 in the past though.

And I can't get IE4 to work at all on my primary test machine. No
idea why. IE3 works (sometimes) and I use it to make sure that
scripts degrade properly as virtually nothing I write will enhance
pages in that browser.

Unfortunately a solution costs real dollars :-S

I've got enough machines, but I don't feel like uninstalling IE6/7
from any of them as I worry it will screw up Windows or other
applications. I still have a Win98 box, but I haven't turned it on in
years. If I determine that the multiple IE on XP approach has
problems I can't work around or discount, perhaps I will uninstall IE6
on the Win98 box and use it to test IE5.x.

 

[Thomas 'PointedEars' Lahn]

[...] For example, from David's code
if (isRealObjectProperty(this, 'document')) {
doc = this.document;
// snip ...
if (isFeaturedMethod(doc, 'getElementById')) {
return function(id, docNode) {
return idCheck((docNode || doc).getElementById(id), id);
};
}
In the call to isFeaturedMethod there is no need to check the typeof
doc. It is already known from the isRealObjectProperty call. This
statement assumes that the isFeaturedMethod and isRealObjects work as
advertised.
I think David will never have the error that you are concerned about
when you write about unqualified references causing an error when the
call is made.

ACK.

I don't know what this means. I rarely know what your abbreviations
mean.

It means ACKnowledge(d) (from the ASCII mnemonic), and it is not my
invention: http://catb.org/~esr/jargon/html/A/ACK.html

You can also find explanations for (hacker) jargon like those abbreviations
in the Wikipedia, e.g. http://en.wikipedia.org/wiki/ACK

That could be done with the following around all the code.

if (typeof this != 'unknown') {

}

Certainly not. `this' is a reference to the Activation Object which can
only be typeof "unknown" if that is a host object. What I meant was that
you will need the equivalent of `global' unless the called context is that
of a user-defined method of the Global Object (where you can use `this').


PointedEars