Do not assign undefined to window event handlers in IE/MSHTML
in [JavaScript]
|
Prev: using screenX and screenY?
Next: ECMA-262-5 in detail. Chapter 1. Properties and Property Descriptors.
From: Garrett Smith on 29 Apr 2010 19:36 Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> Garrett Smith wrote: >>>> A safe way to remove an existing event handler property is to replace >>>> the value with a function the does nothing and returns undefined. The >>>> global noop function `Function.prototype` fits that bill perfectly. >>>> >>>> Example: >>>> hostObject[methodName] = Function.prototype; >> ECMA-262 states: >> >> | The Function prototype object is itself a Function object (its >> | [[Class]] is "Function") that, when invoked, accepts any arguments >> | and returns undefined. > > We've been over this. > Ah, PointedEars, never one to miss an opportunity to harass the FAQ Maintainer with his confusion. And here again... >> Function.prototype returns nothing. > > Irrelevant. > Not irrelevant, but not correct terminology. Function.prototype returns undefined. >> Implementation of Function.prototype that fulfills that could only be >> unsafe if it were to add some side effects. > > Which is not forbidden. > >> The same could be said for String, or any other function. > > No, those are fully specified. > They are as fully specified as Function.prototype. You just apparently didn't take the advice that you so often curtly dish out: RTFM. >> Such side effects would be taking on additional nonstandard >> functionality. Calling Function.prototype with the expectation that it >> has no observable side effects is as safe as calling String, parseInt, >> isNaN with the same expectation. > > Fallacy. > Oh that's just great. "Fallacy". Too lazy to search Wikipedia to find one it might be this time, huh? >> Function.prototype does nothing and returns nothing. > > Wishful thinking, nothing based on fact. > To be the precisely terminology, Function.prototype, when called, returns undefined. >> When the program wants a function that does nothing and returns nothing, >> Function.prototype is a good candidate for that. > > Fallacy. > Again with the generic "fallacy". That conclusion is supported by my understanding of what Function.prototype is. That understanding is supported by the specification and is seen in implementations do. >> var noop = Function.prototype; // Reusable everywhere. > > No. > Well, except in your code, apparently. >> One case where Function.prototype function cannot be used is for new >> expressions; Function.prototype is not specified to implement >> [[Construct]], > > Yes, it is. All "Function objects" must have that property, per section > 13.2. > "13.2 Creating Function Objects" describes the process for creating a user-defined function. There is a difference between built-in and user-defined. *sigh* and after all that discussion of the FAQ entry "What is a built-in object". >> and so a TypeError can be expected. > > Wrong. > No, a TypeError can be expected. The specification clearly states -- and this has been discussed at least twice -- that built-in functions do not have a prototype. This is clearly stated in ECMAScript Eds 3 and 5: ES3 | None of the built-in functions described in this section shall | implement the internal [[Construct]] method unless otherwise specified | in the description of a particular function. ES5: | None of the built-in functions described in this clause that are not | constructors shall implement the [[Construct]] internal method unless | otherwise specified in the description of a particular function. Function.prototype does not implement [[Construct]]. I am pretty sure that I have explained that to you before, on the NG, within the past 12 months. Moreover, that section of your es-matrix document that you linked contains some misinformation as well: | Function.prototype.prototype : Object There is absolutely no reason to make such assertions, as The standard properties for Function.prototype are clearly defined by the specification: They are: toString, apply, call, and, in ES5, bind. Nonetheless, you've highlighted that as a green row, which you explain with: | In addition, features have been highlighted with a greenish background | color if this author considers them safe to use without prior feature | test even when they do not appear to be universally supported. - indicating that Function.prototype.prototype is widely enough supported to be used without first feature testing. Statements from a person who feature tests window prior to assigning the value `undefined` to its onerror property can, with fair likelihood be expected to be false. >> It is unsafe to use Function.prototype function in reusable constructor >> patterns such as those used for prototype inheritance. > > It should not be, side effects aside. > >> var f = Function.prototype; >> f.prototype = MyCtor.prototype; >> var i = new f; // TypeError > > You would have found a bug, then. > Really?! What is the bug? Please do explain exactly what you are expecting, if not TypeError, from the above example, given a function MyCtor. The complete example: function MyCtor(){} var f = Function.prototype; f.prototype = MyCtor.prototype; var i = new f; alert(typeof i); What is the expected result of that program? Do explain why. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 29 Apr 2010 20:53 Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> Garrett Smith wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> Garrett Smith wrote: >>>>> A safe way to remove an existing event handler property is to replace >>>>> the value with a function the does nothing and returns undefined. The >>>>> global noop function `Function.prototype` fits that bill perfectly. >>>>> >>>>> Example: >>>>> hostObject[methodName] = Function.prototype; >>> ECMA-262 states: >>> >>> | The Function prototype object is itself a Function object (its >>> | [[Class]] is "Function") that, when invoked, accepts any arguments >>> | and returns undefined. >> >> We've been over this. > > Ah, PointedEars, never one to miss an opportunity to harass the FAQ > Maintainer with his confusion. And here again... Fallacy. >>> Function.prototype returns nothing. >> Irrelevant. > > Not irrelevant, but not correct terminology. Function.prototype returns > undefined. Which is either irrelevant to the question whether it is a "no-op function" or proves that it is _not_ a "no-op function". >>> Implementation of Function.prototype that fulfills that could only be >>> unsafe if it were to add some side effects. >> >> Which is not forbidden. >> >>> The same could be said for String, or any other function. >> >> No, those are fully specified. > > They are as fully specified as Function.prototype. No, with only a few exceptions there are algorithms specified for those functions that need to be implemented in conforming implementations. > You just apparently didn't take the advice that you so often curtly dish > out: RTFM. F^HRead it yourself. As for String(), the Specification goes: | 15.5.1.1 String ( [ value ] ) | | Returns a String value (not a String object) computed by ToString(value). | If value is not supplied, the empty String "" is returned. That is *a lot* more definitive than for `Function.prototype'. >>> Such side effects would be taking on additional nonstandard >>> functionality. Calling Function.prototype with the expectation that it >>> has no observable side effects is as safe as calling String, parseInt, >>> isNaN with the same expectation. >> Fallacy. > > Oh that's just great. "Fallacy". Too lazy to search Wikipedia to find > one it might be this time, huh? Given the number of your fallacies lately, it is too much of a waste of time for me to look up the English terminology. Get a new logic module, then I might start to take you seriously again. >>> Function.prototype does nothing and returns nothing. >> Wishful thinking, nothing based on fact. > > To be the precisely terminology, Function.prototype, when called, > returns undefined. Which is irrelevant as to what happens between the moment it is called and the moment it returns. >>> When the program wants a function that does nothing and returns nothing, >>> Function.prototype is a good candidate for that. >> >> Fallacy. > > Again with the generic "fallacy". > > That conclusion is supported by my understanding of what > Function.prototype is. That understanding is supported by the > specification and is seen in implementations do. You start gibbering. >>> var noop = Function.prototype; // Reusable everywhere. >> No. > > Well, except in your code, apparently. I find your arguments increasingly strewn with increasingly gaping defects in logic. They are really getting VK-ish. >>> One case where Function.prototype function cannot be used is for new >>> expressions; Function.prototype is not specified to implement >>> [[Construct]], >> Yes, it is. All "Function objects" must have that property, per section >> 13.2. > > "13.2 Creating Function Objects" describes the process for creating a > user-defined function. Yes, that can be inferred. > There is a difference between built-in and user-defined. *sigh* and after > all that discussion of the FAQ entry "What is a built-in object". Fallacy again. >>> and so a TypeError can be expected. >> Wrong. > > No, a TypeError can be expected. > > The specification clearly states -- and this has been discussed at least > twice -- that built-in functions do not have a prototype. > This is clearly stated in ECMAScript Eds 3 and 5: > > ES3 > | None of the built-in functions described in this section shall > | implement the internal [[Construct]] method unless otherwise specified > | in the description of a particular function. > > ES5: > > | None of the built-in functions described in this clause that are not > | constructors shall implement the [[Construct]] internal method unless > | otherwise specified in the description of a particular function. > > Function.prototype does not implement [[Construct]]. [...] ACK > Moreover, that section of your es-matrix document that you linked > contains some misinformation as well: Rubbish. > | Function.prototype.prototype : Object > > There is absolutely no reason to make such assertions, Yes, there is. > as The standard properties for Function.prototype are clearly defined by > the specification: They are: toString, apply, call, and, in ES5, bind. Irrelevant. > Nonetheless, you've highlighted that as a green row, which you explain > with: > > | In addition, features have been highlighted with a greenish background > | color if this author considers them safe to use without prior feature > | test even when they do not appear to be universally supported. | This assessment is mostly based on the fact that the versions of the | implementations the features require can be considered obsolete because | the user agents known to implement them can be considered obsolete (see | the respective version information for details). Note that this assessment | is likely to be subject to change as more implementations are evaluated. | If taken as a recommendation for design decisions, it should be taken as ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | a light one. ^^^^^^^^^^^^ > - indicating that Function.prototype.prototype is widely enough > supported to be used without first feature testing. See below. > Statements from a person who feature tests window By contrast, `window' is actually a *host-defined* property which is therefore going to be test subject for the *DOM* Support Matrix (I have only included it in the ES Matrix for completeness, since it was documented as being part of JavaScript for quite some time) before I consider not feature- testing it. > prior to assigning the value `undefined` to its onerror property Idiot. Assigning `undefined' there was unintentional. RTFT. > can, with fair likelihood be expected to be false. Idiot. The highlighting is automatically based on the information I could enter so far. Which in this case is almost nothing, so ... Suffice it to say that Function.prototype.prototype does refer to an Object instance in JavaScript 1.8.2, and perhaps earlier versions, which, after tests, is going to be documented accordingly. 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> (404-comp.)
From: Garrett Smith on 29 Apr 2010 23:37 Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> Garrett Smith wrote: >>>> Thomas 'PointedEars' Lahn wrote: >>>>> Garrett Smith wrote: >>>>>> A safe way to remove an existing event handler property is to replace >>>>>> the value with a function the does nothing and returns undefined. The >>>>>> global noop function `Function.prototype` fits that bill perfectly. >>>>>> >>>>>> Example: >>>>>> hostObject[methodName] = Function.prototype; >>>> ECMA-262 states: >>>> >>>> | The Function prototype object is itself a Function object (its >>>> | [[Class]] is "Function") that, when invoked, accepts any arguments >>>> | and returns undefined. >>> We've been over this. >> Ah, PointedEars, never one to miss an opportunity to harass the FAQ >> Maintainer with his confusion. And here again... > > Fallacy. > >>>> Function.prototype returns nothing. >>> Irrelevant. >> Not irrelevant, but not correct terminology. Function.prototype returns >> undefined. > > Which is either irrelevant to the question whether it is a "no-op function" > or proves that it is _not_ a "no-op function". > >>>> Implementation of Function.prototype that fulfills that could only be >>>> unsafe if it were to add some side effects. >>> Which is not forbidden. >>> >>>> The same could be said for String, or any other function. >>> No, those are fully specified. >> They are as fully specified as Function.prototype. > > No, with only a few exceptions there are algorithms specified for those > functions that need to be implemented in conforming implementations. > >> You just apparently didn't take the advice that you so often curtly dish >> out: RTFM. > > F^HRead it yourself. You have posted misinformation here on this thread and on your website. The one of us that has not read (or understood) the specification is you. As for String(), the Specification goes: > > | 15.5.1.1 String ( [ value ] ) > | > | Returns a String value (not a String object) computed by ToString(value). > | If value is not supplied, the empty String "" is returned. > > That is *a lot* more definitive than for `Function.prototype'. > That definition is an algorithm definition. It does not imply the use of any specific implementation technique. In practice, there may be more efficient algorithms available to implement a given feature. The definition for Function.prototype completely describes the expected behavior that is seen in implementations. | The Function prototype object is itself a Function object (its | [[Class]] is "Function") that, when invoked, accepts any arguments and | returns undefined. And if that is enough, then perhaps somebody (and hopefully someone who has demonstrated a more rational line of thinking) might state why it is confusing. Indeed, it would seem like a Pointless waste of space to have such algorithm there, e.g. | 1. Return. Would anyone care to see that included in the specification? The specification authors have issues of greater significance to worry about such pedantic nonsense. And so the absence of such algorithm does not mean that there may be side effects any more than the absence of mention of side effects for parseInt means there may be side effects. The algorithms in the specification are used to clarify semantics. >>>> Such side effects would be taking on additional nonstandard >>>> functionality. Calling Function.prototype with the expectation that it >>>> has no observable side effects is as safe as calling String, parseInt, >>>> isNaN with the same expectation. >>> Fallacy. >> Oh that's just great. "Fallacy". Too lazy to search Wikipedia to find >> one it might be this time, huh? > > Given the number of your fallacies lately, it is too much of a waste of time > for me to look up the English terminology. Get a new logic module, then I > might start to take you seriously again. > There a few fallacies there. The first is that it is too much of a waste of time for you. It is obvious that you love wasting time, so your statement is obviously untrue. That is a non sequitur. The second fallacy is that you provided a false statement to support the claim that htere are a number of fallacies lately. The second is a Tu Quoque. I post something correct, then you want to say that its wrong or nonsense. It usually takes several posts to get the message through. You went as far recently as to posting blatant lies about the intentions of what I wrote. There was the long argument about authors serving invalid HTML are expecting nonstandard behavior. All of these things take time away from other things that I do, which includes maintaining the FAQ. >>>> Function.prototype does nothing and returns nothing. >>> Wishful thinking, nothing based on fact. >> To be the precisely terminology, Function.prototype, when called, >> returns undefined. > > Which is irrelevant as to what happens between the moment it is called and > the moment it returns. > The definition in the specification is as clear and precise as needed. >>>> When the program wants a function that does nothing and returns nothing, >>>> Function.prototype is a good candidate for that. >>> Fallacy. >> Again with the generic "fallacy". >> >> That conclusion is supported by my understanding of what >> Function.prototype is. That understanding is supported by the >> specification and is seen in implementations do. > > You start gibbering. > I missed the word "what" before implementations. >>>> var noop = Function.prototype; // Reusable everywhere. >>> No. >> Well, except in your code, apparently. > > I find your arguments increasingly strewn with increasingly gaping defects > in logic. They are really getting VK-ish. > What does VK have to do with this? >>>> One case where Function.prototype function cannot be used is for new >>>> expressions; Function.prototype is not specified to implement >>>> [[Construct]], >>> Yes, it is. All "Function objects" must have that property, per section >>> 13.2. >> "13.2 Creating Function Objects" describes the process for creating a >> user-defined function. > > Yes, that can be inferred. > >> There is a difference between built-in and user-defined. *sigh* and after >> all that discussion of the FAQ entry "What is a built-in object". > > Fallacy again. > No fallacy at all. [...] > ACK > Keep coughing. To yourself. >> Moreover, that section of your es-matrix document that you linked >> contains some misinformation as well: > > Rubbish. > >> | Function.prototype.prototype : Object >> >> There is absolutely no reason to make such assertions, > > Yes, there is. > Ah, another (worthless) unsupported assertion that, unsurprisingly, happens to be false. I earlier posted the first paragraph for Function.prototype. I will post and explain the second paragraph from the specification, for the whiny baby who refuses to read it himself. When a property is to be resolved, the object itself is searched first. If the object does not contain a property, the prototype chain is searched. Thus, a resolution of `Function.prototype.prototype` must first attempt to resolve a property named "prototype" on `Function.prototype`. Function.prototype does not contain a prototype property and so the [[prototype]] for Function.prototype is searched. That object is `Object.prototype`. | The value of the [[Prototype]] internal property of the Function | prototype object is the standard built-in Object prototype object | (15.2.4). Object.prototype is next in the prototype chain and it does not have a prototype property either. Object.prototype has: constructor toString toLocaleString valueOf hasOwnProperty isPrototypeOf propertyIsEnumerable | The value of the [[Prototype]] internal property of the Object | prototype object is null, the value of the [[Class]] internal property | is "Object", and the initial value of the [[Extensible]] internal | property is true. Object.prototype does not have a prototype, and so the property resolution ends at the end of the prototype chain and the value undefined is returned. This is redundantly stated elsewhere in the specification: | Every built-in prototype object has the Object prototype object, which | is the initial value of the expression Object.prototype (15.2.3.1), as | the value of its internal [[Prototype]] property, except the Object | prototype object itself. >> as The standard properties for Function.prototype are clearly defined by >> the specification: They are: toString, apply, call, and, in ES5, bind. > > Irrelevant. > I see a lot of irrelevance. It is coming not from the standard, but from you. Again, my point is that Function.prototype is a function that accepts any number of arguments and returns undefined. One word snips like "Fallacy," "No," "Wishful thinking," "Wrong," "Irrelevant," all the while being totally wrong, each and every time, is irrelevant. Dragging VK into this is irrelevant. >> Nonetheless, you've highlighted that as a green row, which you explain >> with: >> >> | In addition, features have been highlighted with a greenish background >> | color if this author considers them safe to use without prior feature >> | test even when they do not appear to be universally supported. > > | This assessment is mostly based on the fact that the versions of the > | implementations the features require can be considered obsolete because > | the user agents known to implement them can be considered obsolete (see > | the respective version information for details). Note that this assessment > | is likely to be subject to change as more implementations are evaluated. > | If taken as a recommendation for design decisions, it should be taken as > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > | a light one. > ^^^^^^^^^^^^ > Saying that your advice should be "taken lightly" should not be considered as anything other than a weak attempt at self-deprecating humor. You have shown incompetence and unreliability several times in this thread and have wasted a considerable amount of time in doing that. 1) Stating that Function.prototype implements construct; once with your assigning undefined to window.onerror, 2) Stating that Function.prototype could not be reused everywhere 3) Stating that expecting a TypeError out of using Function.prototype in a NewExpression was wrong. 4) Assigning window.onerror a value undefined and wondering why it throws errors (then laughably calling me an idiot for that). >> - indicating that Function.prototype.prototype is widely enough >> supported to be used without first feature testing. > > See below. > >> Statements from a person who feature tests window > > By contrast, `window' is actually a *host-defined* property which is > therefore going to be test subject for the *DOM* Support Matrix (I have only > included it in the ES Matrix for completeness, since it was documented as > being part of JavaScript for quite some time) before I consider not feature- > testing it. > >> prior to assigning the value `undefined` to its onerror property > > Idiot. Assigning `undefined' there was unintentional. RTFT. > Let met get this straight. You had a bug, you couldn't figure it out on your own, and now I'm an idiot?! >> can, with fair likelihood be expected to be false. > > Idiot. The highlighting is automatically based on the information I could > enter so far. Which in this case is almost nothing, so ... > > Suffice it to say that Function.prototype.prototype does refer to an Object > instance in JavaScript 1.8.2, and perhaps earlier versions, which, after > tests, is going to be documented accordingly. > I don't care. Looking at the one place you pointed (misled, really) the reader to had wrong information and you couldn't be bothered to read the manual when I pointed it out, so I had to do it for you. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Lasse Reichstein Nielsen on 30 Apr 2010 06:07 Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes: > Suffice it to say that Function.prototype.prototype does refer to an Object > instance in JavaScript 1.8.2, and perhaps earlier versions, which, after > tests, is going to be documented accordingly. As data points for non JavaScript browsers: IE 8: undefined IE 9 prview: undefined Opera 9.52: undefined Safari 4.0.5 undefined Chrome dev : null Mozilla seems to be alone in having Function.prototype.prototype be an object, a fresh object with a constructor property satisfying Function.prototype.prototype.constructor == Function.prototype /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Thomas 'PointedEars' Lahn on 30 Apr 2010 06:20
Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> Garrett Smith wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> Garrett Smith wrote: >>>>> Implementation of Function.prototype that fulfills that could only be >>>>> unsafe if it were to add some side effects. >>>> Which is not forbidden. >>>> >>>>> The same could be said for String, or any other function. >>>> No, those are fully specified. >>> They are as fully specified as Function.prototype. >> >> No, with only a few exceptions there are algorithms specified for those >> functions that need to be implemented in conforming implementations. >> >>> You just apparently didn't take the advice that you so often curtly dish >>> out: RTFM. >> >> F^HRead it yourself. > > You have posted misinformation here on this thread and on your website. > The one of us that has not read (or understood) the specification is you. Rubbish. >> As for String(), the Specification goes: >> >> | 15.5.1.1 String ( [ value ] ) >> | >> | Returns a String value (not a String object) computed by >> | ToString(value). If value is not supplied, the empty String "" is >> | returned. >> >> That is *a lot* more definitive than for `Function.prototype'. > > That definition is an algorithm definition. It does not imply the use of > any specific implementation technique. In practice, there may be more > efficient algorithms available to implement a given feature. Regardless, it does say exactly what, in essence, must and therefore what must not happen between call and return. > The definition for Function.prototype completely describes the expected > behavior that is seen in implementations. > > | The Function prototype object is itself a Function object (its > | [[Class]] is "Function") that, when invoked, accepts any arguments and > | returns undefined. Again, that does _not_ say what can happen between the moment the function is called and the moment it returns. So it does _not_ support your assumption that the function would be a "no-op" either way. >>>>> Such side effects would be taking on additional nonstandard >>>>> functionality. Calling Function.prototype with the expectation that it >>>>> has no observable side effects is as safe as calling String, parseInt, >>>>> isNaN with the same expectation. >>>> Fallacy. >>> Oh that's just great. "Fallacy". Too lazy to search Wikipedia to find >>> one it might be this time, huh? >> >> Given the number of your fallacies lately, it is too much of a waste of >> time >> for me to look up the English terminology. Get a new logic module, then >> I might start to take you seriously again. >> > There a few fallacies there. > > The first is that it is too much of a waste of time for you. No, it isn't. > It is obvious that you love wasting time, No, it isn't, I don't. In fact, I have just pointed out that I don't. Another fallacy of yours. > so your statement is obviously untrue. That is a non sequitur. Your "conclusion" is a non sequitur par excellence instead. > The second fallacy is that you provided a false statement to support the > claim that htere are a number of fallacies lately. No, I have stated them. Can't you do simple arithmetic? > The second is a Tu Quoque. [...] You are not up to par here. Give it up. >>>>> Function.prototype does nothing and returns nothing. >>>> Wishful thinking, nothing based on fact. >>> To be the precisely terminology, Function.prototype, when called, >>> returns undefined. >> >> Which is irrelevant as to what happens between the moment it is called >> and the moment it returns. > > The definition in the specification is as clear and precise as needed. And anything that is not written there is mere assumption (of yours). >>>>> var noop = Function.prototype; // Reusable everywhere. >>>> No. >>> Well, except in your code, apparently. >> I find your arguments increasingly strewn with increasingly gaping >> defects in logic. They are really getting VK-ish. > > What does VK have to do with this? You are beginning to sound like him. That should make you think. >>>>> One case where Function.prototype function cannot be used is for new >>>>> expressions; Function.prototype is not specified to implement >>>>> [[Construct]], >>>> Yes, it is. All "Function objects" must have that property, per >>>> section 13.2. >>> "13.2 Creating Function Objects" describes the process for creating a >>> user-defined function. >> >> Yes, that can be inferred. >> >>> There is a difference between built-in and user-defined. *sigh* and >>> after all that discussion of the FAQ entry "What is a built-in object". >> >> Fallacy again. > > No fallacy at all. Yes, it is. The discussion has nothing to do with this. > [...] > >> ACK > > Keep coughing. To yourself. ACK means acknowledge(d), from the ASCII mnemonic, as opposed to "Ack(!)". >>> Moreover, that section of your es-matrix document that you linked >>> contains some misinformation as well: >> >> Rubbish. >> >>> | Function.prototype.prototype : Object >>> >>> There is absolutely no reason to make such assertions, >> >> Yes, there is. > > Ah, another (worthless) unsupported assertion that, unsurprisingly, > happens to be false. [...] No, I have showed you that and why there is a reason to write it like that. That you choose to ignore it and try to distort the meaning of the description and the highlighting in the Matrix, to ascribe meaning to it that it simply is not intended to have, is your problem alone. (I'm sure you'll find out eventually what kind of fallacy that is.) >>> Nonetheless, you've highlighted that as a green row, which you explain >>> with: >>> >>> | In addition, features have been highlighted with a greenish background >>> | color if this author considers them safe to use without prior feature >>> | test even when they do not appear to be universally supported. >> >> | This assessment is mostly based on the fact that the versions of the >> | implementations the features require can be considered obsolete because >> | the user agents known to implement them can be considered obsolete (see >> | the respective version information for details). Note that this >> | assessment is likely to be subject to change as more implementations >> | are evaluated. If taken as a recommendation for design decisions, it >> | should be taken as >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> | a light one. >> ^^^^^^^^^^^^ > > Saying that your advice should be "taken lightly" should not be > considered as anything other than a weak attempt at self-deprecating > humor. No, this is about *versions* of *implementations*. "Universally supported" obviously means that a feature is supported by all versions of all listed implementations. Since some versions can be/must be considered obsolete ... > [snip ad hominem attack] > >>> - indicating that Function.prototype.prototype is widely enough >>> supported to be used without first feature testing. >> >> See below. >> >>> Statements from a person who feature tests window >> >> By contrast, `window' is actually a *host-defined* property which is >> therefore going to be test subject for the *DOM* Support Matrix (I have >> only included it in the ES Matrix for completeness, since it was >> documented as being part of JavaScript for quite some time) before I >> consider not feature- testing it. >> >>> prior to assigning the value `undefined` to its onerror property >> >> Idiot. Assigning `undefined' there was unintentional. RTFT. > > Let met get this straight. You had a bug, Yes. > you couldn't figure it out on your own, No, I could. I had a little help in finding the position of the bug. > and now I'm an idiot?! You are an idiot for insinuating that I had assigned `undefined' intentionally, not knowing that that would be error-prone, when there was/is sufficient evidence to suggest otherwise (`if (jsx_object.isMethod(fHandler))'). >>> can, with fair likelihood be expected to be false. >> >> Idiot. The highlighting is automatically based on the information I >> could enter so far. Which in this case is almost nothing, so ... >> >> Suffice it to say that Function.prototype.prototype does refer to an >> Object instance in JavaScript 1.8.2, and perhaps earlier versions, which, >> after tests, is going to be documented accordingly. > > I don't care. Looking at the one place you pointed (misled, really) the > reader to had wrong information and you couldn't be bothered to read the > manual when I pointed it out, so I had to do it for you. I usually write for *intelligent* people. When I am publishing a trunk version (so as for the interested reader not to wait for the completed table), I am explaining what the marking is based on, and there is only one column for an implementation of a row filled with data, and the single implementation version is not even marked as tested, I presume they are able to connect the dots. However, I have been working on an "unsafe" marking (see the comment) that is intended to take care of such misconceptions. 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> (404-comp.) |