New Host Object Primer
in [JavaScript]
|
Prev: FAQ Topic - Internationalisation and Multinationalisation in javascript. (2010-03-23)
Next: buy online Diazepam, purchase Diazepamwithout a prescription, buy Diazepamon line no prescription
From: David Mark on 23 Mar 2010 21:20 Garrett Smith wrote: > David Mark wrote: >> Thomas 'PointedEars' Lahn wrote: >>> David Mark wrote: >>> >>>> Garrett Smith wrote: >>>>> Thomas 'PointedEars' Lahn wrote: >>>>>> var reFeaturedMethod = new RegExp('^(function|object)$', 'i > [...] > >>> But AISB the `!!' does not really save anything as in a boolean >>> context the return value would be subject to type conversion anyway. >> >> That's true. But I prefer to have the function return booleans only. >> > Having gthe function return boolean provides clear expectations to the > caller. WIth an "is" method, the caller should be able to expect a > boolean value. > > This expectation could be clearly defined by a unit test. I might write > it like this: > > "testIsHostMethod - contains" : function(){ > var actualResult = isHostMethod(document.body.contains); > Assert.isTrue(actualResult); > } isHostMethod(document.body, 'contains') But I don't see that as a good unit test for this method as it will fail if that host method is missing. I would prefer to simply test that the result is a boolean. > > That isHostMethod returning something other than false would end up > failing that test. By always returning boolean value, the expectation is > simpler. Perhaps I am reading your test wrong. Did you mean something like isBoolean (and returns something other than true/false?) > >>>>> Caveats: >>>>> Object `o` could be callable and falsish, such as nonstandard callable >>>>> "document.all". >>> Is there a good reason for document.all(...) instead of >>> document.all[...]? >>> If not, that fact is largely irrelevant. >> >> I missed that that second part was mentioned. I already mentioned about >> the sometimes callable objects in the explanation and documentation. >> Don't request an opinion from isHostMethod on those. >> > > I was not suggesting a workaround for the document.all anomaly. > > The use of document.all should be abstained from. Absolutely. > >>> >>>>> Object `o` could be the `item` method, for which typeof will result >>>>> "string" in IE. This would result in isHostMethod returning false. >>>> Yes, I should add both of those stipulations to the docs and this >>>> example. >>> That argument only makes sense if _o[m]_ refers to the item() method >>> of NodeList or HTMLCollection implementations. Then again, is there >>> a good reason to call o.item(i) instead of accessing o[i]? If not, >>> that fact is largely irrelevant. >>> >> >> Right. It is odd that the one exception to an otherwise golden rule is >> something you would/should never need anyway. Still, it's an >> interesting caveat and I think I will mention it. > > I can't think of a good reason for preferring item() over []. Me neither. I've never used it. > > I recall testing Firefox up to 1.5 and [] was faster than item() there. > Browsers nowadays are so fast that that difference (which may not exist > any longer) would hardly matter much. Less operations would seem to indicate it would be faster, but you can never be 100% sure with such a small variation (and, as noted, it's not likely to be a significant difference anyway).
From: Garrett Smith on 24 Mar 2010 00:46 David Mark wrote: > Garrett Smith wrote: >> David Mark wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> David Mark wrote: >>>> >>>>> Garrett Smith wrote: >>>>>> Thomas 'PointedEars' Lahn wrote: >>>>>>> var reFeaturedMethod = new RegExp('^(function|object)$', 'i >> [...] >> >>>> But AISB the `!!' does not really save anything as in a boolean >>>> context the return value would be subject to type conversion anyway. >>> That's true. But I prefer to have the function return booleans only. >>> >> Having gthe function return boolean provides clear expectations to the >> caller. WIth an "is" method, the caller should be able to expect a >> boolean value. >> >> This expectation could be clearly defined by a unit test. I might write >> it like this: >> >> "testIsHostMethod - contains" : function(){ >> var actualResult = isHostMethod(document.body.contains); >> Assert.isTrue(actualResult); >> } > > isHostMethod(document.body, 'contains') > Right. > But I don't see that as a good unit test for this method as it will fail > if that host method is missing. I would prefer to simply test that the > result is a boolean. > >> That isHostMethod returning something other than false would end up >> failing that test. By always returning boolean value, the expectation is >> simpler. > > Perhaps I am reading your test wrong. Did you mean something like > isBoolean (and returns something other than true/false?) > No, that makes sense, but it is not what I meant. I was going for testing under known conditions, that the method does what is expected it will do. A "contains" method will be absent in some implementations, so no good as test. A valid test might be to set up a case where the result is known or assumed to be true or false. For example, if the test case assumes that the environment has a `document.getElementById` that is potentially callable and that `document.title` would never be callable: testIsHostMethodWithDomCoreMethod : function() { Assert.isTrue(isHostMethod(document, "getElementById")); } testIsHostMethodWithNonCallableObject : function() { Assert.isFalse(isHostMethod(document, "title")); } The expected outcome could also be dynamic. For example: "testIsHostMethod - element.contains()" : function() { // First determine if calling something either works or doesn't. var expectedCallability = (function(){ try { document.body.contains(document.body); return true; } catch(ex) { return false; } })(); Assert.areSame(expectedCallability , isHostMethod(document.body, "contains"); } The only problem with this is that testing a property such as `document.forms` or `document.images` will be true, but not always callable. [...] -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 25 Mar 2010 15:43 David Mark wrote: > Garrett Smith wrote: >> David Mark wrote: >>> Garrett Smith wrote: >>>> David Mark wrote: >>>>> I have posted a new primer related to host objects and feature >>>>> detection/testing. >>>>> >>>>> http://www.cinsoft.net/host.html >>>>> >>>> | The isHostObjectProperty function tests if the specified host object >>>> | property references an object that is safe to evaluate. >>>> >>>> The term "evaluate" is non-standard terminology. What do you mean? >>> Anything along the lines of type conversion, assigning a reference to a >>> variable, etc. What would you call it? >> I like to see the standard terminology to describe the problems. > > Yes, and that would be what in this case? I mean a single word to > replace evaluate. I realized when I wrote it it wasn't technically > specified, but couldn't come up with a better word. > >> I mentioned a few of the problems with host objects here: >> >> http://jibbering.com/faq/notes/code-guidelines/#hostObjects > > Yes, and speaking of the FAQ:- > > http://www.jibbering.com/faq/#onlineResources > > ...needs section for browser scripting resources (e.g. mine, Kangax' > blog, etc.) And:- > > http://www.jibbering.com/faq/faq_notes/contributors.html > > ...needs my name added. At the very least, the confirm issue I fixed:- > > http://www.jibbering.com/faq/#changeBrowserDialog > There are a lot of folks who have provided feedback to the FAQ. If you search for subjects with "FAQ_Updated" (replace "_" with " "), you'll find a lot more folks. My idea is to create a new contributors' page under /faq/notes/contributors/ >> Posted inline, for convenience: >> | Host Objects: >> | >> | * Operators: >> | o Do not use delete operator with host object (IE Errors) > > Sound, but I would ditch the parenthetical. Could happen to any browser. > >> | o Do not add any expando properties (unselectable is safe) > > What is this one's aside about? > An "expando" is Microsoft terminology for user-defined properties that get added on to an IE host object. For example:- // ERROR-PRONE. DO NOT DO THIS. if(typeof e.pageX == "undefined") { e.pageX = calculatePageX(); } The execption to the rule is `unselectable` property of "DHTML Objects". See also: <URL: http://msdn.microsoft.com/en-us/library/ms534706%28VS.85%29.aspx > <URL: http://msdn.microsoft.com/en-us/library/ms533747%28VS.85%29.aspx > >> | o Host objects that error upon [[Get]] access are often ActiveX >> | objects. These include, but are not limited to: > > Host object _properties_ that throw errors on [[Get]] (a term that is > too subterranean for my primers) often indicate that the containing > object is an ActiveX implementation. All such method properties do it. > I am not sure that that is true. For example:- element.filters.alpha will result in error in some cases ("Unspecified error", IIRC. A quick search indicates that error here: http://www.dynamicdrive.com/forums/showthread.php?t=40912 The OP mentioned that he suspected IE preference "Binary and Script Behaviors" disabled as being a possible culprit. The solution posted there uses CC. Manipulating the filter string is sufficient, smaller, simpler, and easier to read (as discussed here). >> | + Disconnected nodes whose parentNode is not an element >> | (node.offsetParent) > > In some cases, all properties of element nodes go AWOL ("unknown" typeof > results). IIRC, that happens when they are orphaned by an innerHTML > replacement. > I have read of this but have not seen it first hand. >> | + XMLHttpRequest methods (open, send, etc). > > And its ActiveX equivalents. > >> | + filters: elem.filters.alpha, elem.style.filters.alpha, etc. > > The filters object is implemented with ActiveX, so its properties are > suspect. > >> | + document.styleSheets[99999] - Error from [[Get]] for a >> | nonexistent numeric property of a styleSheets collection. > > That one may not be due to ActiveX, but just an allowable exception for > an out of bounds request. > I haven't dug deep enough to know, but I would not be surprised if it is related to ActiveX. As discussed previously: javascript: alert(typeof document.styleSheets[9999]) >> | + link.href for nntp: links in IE. > > Yes, the Stockton href incident. That one was truly unexpected (and > likely a bug) as how else are you to get the href value. (!) > >> | + NodeList in Safari 2 - do not attempt access a nonexistent >> | property (e.g. document.childNodes.slice). > > That's an odd one. Likely also a bug. > That's an *old* one. Prototype JS had that issue; kangax posted how `typeof` test did not avoid the crash. (the solution was to use an `in` operator test). >> | >> | * Type conversion >> | [[ToString]] >> | Perform string conversion by starting concatenation with a string >> | value. See Newsgroup message explanation. >> <URL: >> http://groups.google.bg/group/comp.lang.javascript/msg/1528f612e31f09fe > > > I don't see how the explanation relates to host objects, which don't > have to follow the specs at all. The linked newsgroup message shows how string conversion of host object does not follow the specification for string conversion. The linked message serves as an example of showing that these host objects are fragile and can't be trusted. I would like to finish the entry on "What is a host object", link from that, to this "code guidelines" note. I would also like to mention that when typeof operator results "unknown", then the object is unsafe. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 25 Mar 2010 16:29 Garrett Smith wrote: > David Mark wrote: >> Garrett Smith wrote: >>> David Mark wrote: >>>> Garrett Smith wrote: >>>>> David Mark wrote: >>>>>> I have posted a new primer related to host objects and feature >>>>>> detection/testing. >>>>>> >>>>>> http://www.cinsoft.net/host.html >>>>>> >>>>> | The isHostObjectProperty function tests if the specified host object >>>>> | property references an object that is safe to evaluate. >>>>> >>>>> The term "evaluate" is non-standard terminology. What do you mean? >>>> Anything along the lines of type conversion, assigning a reference to a >>>> variable, etc. What would you call it? >>> I like to see the standard terminology to describe the problems. >> >> Yes, and that would be what in this case? I mean a single word to >> replace evaluate. I realized when I wrote it it wasn't technically >> specified, but couldn't come up with a better word. >> >>> I mentioned a few of the problems with host objects here: >>> >>> http://jibbering.com/faq/notes/code-guidelines/#hostObjects >> >> Yes, and speaking of the FAQ:- >> >> http://www.jibbering.com/faq/#onlineResources >> >> ...needs section for browser scripting resources (e.g. mine, Kangax' >> blog, etc.) And:- >> >> http://www.jibbering.com/faq/faq_notes/contributors.html >> >> ...needs my name added. At the very least, the confirm issue I fixed:- >> >> http://www.jibbering.com/faq/#changeBrowserDialog >> > > There are a lot of folks who have provided feedback to the FAQ. If you > search for subjects with "FAQ_Updated" (replace "_" with " "), you'll > find a lot more folks. What do they have to do with me? :) > > My idea is to create a new contributors' page under > /faq/notes/contributors/ Why not add my name to the old one in the interim? Seems prudent. > > >>> Posted inline, for convenience: >>> | Host Objects: >>> | >>> | * Operators: >>> | o Do not use delete operator with host object (IE Errors) >> >> Sound, but I would ditch the parenthetical. Could happen to any browser. >> >>> | o Do not add any expando properties (unselectable is safe) >> >> What is this one's aside about? >> > > An "expando" is Microsoft terminology for user-defined properties that > get added on to an IE host object. For example:- That's everyone's term for properties that augment host objects. > > // ERROR-PRONE. DO NOT DO THIS. > if(typeof e.pageX == "undefined") { > e.pageX = calculatePageX(); > } Yes, Dojo does stuff like that _everywhere_. Can lead to memory leaks in non-IE browsers. Do not augment host objects, period. ;) > > The execption to the rule is `unselectable` property of "DHTML Objects". I'm not buying that and nobody should be selling it. :) > > See also: > <URL: http://msdn.microsoft.com/en-us/library/ms534706%28VS.85%29.aspx > > <URL: http://msdn.microsoft.com/en-us/library/ms533747%28VS.85%29.aspx > No thanks! I've wasted enough of my life reading MS' misconceptions. > >>> | o Host objects that error upon [[Get]] access are often ActiveX >>> | objects. These include, but are not limited to: >> >> Host object _properties_ that throw errors on [[Get]] (a term that is >> too subterranean for my primers) often indicate that the containing >> object is an ActiveX implementation. All such method properties do it. >> > > I am not sure that that is true. For example:- > > element.filters.alpha > > will result in error in some cases ("Unspecified error", IIRC. That is a property of a host object (filters). > > A quick search indicates that error here: > http://www.dynamicdrive.com/forums/showthread.php?t=40912 There's no need to worry about specific cases if you follow the rules. ;) > > The OP mentioned that he suspected IE preference "Binary and Script > Behaviors" disabled as being a possible culprit. I can guarantee the OP is using a multi-IE installation. Those don't work well with the DirectX interfaces (even Microsoft's own examples blow up with that error). There's no reason to worry about that as the multi-IE things are just crawling with bugs. Just so happens we've discussed that one before with regard to getting opacity (back around the end of 2007 IIRC). > > The solution posted there uses CC. Manipulating the filter string is > sufficient, smaller, simpler, and easier to read (as discussed here). That's what we came up with back then (getting/setting the filter string, but not using CC). > >>> | + Disconnected nodes whose parentNode is not an element >>> | (node.offsetParent) >> >> In some cases, all properties of element nodes go AWOL ("unknown" typeof >> results). IIRC, that happens when they are orphaned by an innerHTML >> replacement. >> > > I have read of this but have not seen it first hand. I see it pop up in larger Web apps from time to time, usually when I remove an ostensibly unneeded try-catch and find out that the original authors were shielding themselves from their own mistakes (i.e. catching an exception that arose due to some unrelated breakdown in logic). > >>> | + XMLHttpRequest methods (open, send, etc). >> >> And its ActiveX equivalents. >> >>> | + filters: elem.filters.alpha, elem.style.filters.alpha, etc. >> >> The filters object is implemented with ActiveX, so its properties are >> suspect. >> > > >>> | + document.styleSheets[99999] - Error from [[Get]] for a >>> | nonexistent numeric property of a styleSheets collection. >> >> That one may not be due to ActiveX, but just an allowable exception for >> an out of bounds request. >> > > I haven't dug deep enough to know, but I would not be surprised if it is > related to ActiveX. As discussed previously: > > javascript: alert(typeof document.styleSheets[9999]) What about it? The styleSheets object may be implemented as ActiveX. Check the typeof results of its methods to find out (will be "unknown"). > >>> | + link.href for nntp: links in IE. >> >> Yes, the Stockton href incident. That one was truly unexpected (and >> likely a bug) as how else are you to get the href value. (!) >> >>> | + NodeList in Safari 2 - do not attempt access a nonexistent >>> | property (e.g. document.childNodes.slice). >> >> That's an odd one. Likely also a bug. >> > > That's an *old* one. Prototype JS had that issue; kangax posted how > `typeof` test did not avoid the crash. (the solution was to use an `in` > operator test). Yes, I remember it well. It's the one case I've heard of where typeof throws an exception (proving the rule). > >>> | >>> | * Type conversion >>> | [[ToString]] >>> | Perform string conversion by starting concatenation with a string >>> | value. See Newsgroup message explanation. >>> <URL: >>> http://groups.google.bg/group/comp.lang.javascript/msg/1528f612e31f09fe >>> > >> >> I don't see how the explanation relates to host objects, which don't >> have to follow the specs at all. > > The linked newsgroup message shows how string conversion of host object > does not follow the specification for string conversion. I wouldn't expect it to. Such expectations invariably lead to disappointment. > The linked > message serves as an example of showing that these host objects are > fragile and can't be trusted. Yet another one. > > I would like to finish the entry on "What is a host object", link from > that, to this "code guidelines" note. > > I would also like to mention that when typeof operator results > "unknown", then the object is unsafe. Whatever. You need to add a section to the online resources to link to some good browser scripting material.
From: Garrett Smith on 25 Mar 2010 19:18
David Mark wrote: > Garrett Smith wrote: >> David Mark wrote: >>> Garrett Smith wrote: >>>> David Mark wrote: >>>>> Garrett Smith wrote: >>>>>> David Mark wrote: >>>>>>> I have posted a new primer related to host objects and feature >>>>>>> detection/testing. >>>>>>> >>>>>>> http://www.cinsoft.net/host.html >>>>>>> Regarding that url, I suggest moving it to obscure the filename and underlying technology. you might also want to move it to an "articles" section, to keep a clean directory structure. The more articles you write, the more there will be under "/" plus demos, etc. I would probably use a URI such as: http://example.com/articles/host/ [...] I also do not understand the title: "H is for Host" Is this a cookie monster spin-off? http://www.youtube.com/watch?v=BovQyphS8kA >>> >> There are a lot of folks who have provided feedback to the FAQ. If you >> search for subjects with "FAQ_Updated" (replace "_" with " "), you'll >> find a lot more folks. > > What do they have to do with me? :) > Like you, they have provided useful contribution to the FAQ. Like you, they have not been included on a contributors page. A lot of guys have contributed a lot of stuff. >> My idea is to create a new contributors' page under >> /faq/notes/contributors/ > > Why not add my name to the old one in the interim? Seems prudent. > Too many problems with the old pages. The markup, the navigation, the urls, and the content. If somebody wants to create a contributors page -- send me an email or post it here and I'll upload it. The FAQ pages are all using the HTML 4.01 strict doctype and validate. >> >>>> Posted inline, for convenience: >>>> | Host Objects: >>>> | >>>> | * Operators: >>>> | o Do not use delete operator with host object (IE Errors) >>> Sound, but I would ditch the parenthetical. Could happen to any browser. >>> >>>> | o Do not add any expando properties (unselectable is safe) >>> What is this one's aside about? >>> >> An "expando" is Microsoft terminology for user-defined properties that >> get added on to an IE host object. For example:- > > That's everyone's term for properties that augment host objects. > >> // ERROR-PRONE. DO NOT DO THIS. >> if(typeof e.pageX == "undefined") { >> e.pageX = calculatePageX(); >> } > > Yes, Dojo does stuff like that _everywhere_. Can lead to memory leaks > in non-IE browsers. Do not augment host objects, period. ;) > It can result in errors, too. When a property is defined as a "getter" and no setter is defined. MouseEvent.prototype.pageX, for example, is a getter in at least one implementation. >> The execption to the rule is `unselectable` property of "DHTML Objects". > > I'm not buying that and nobody should be selling it. :) > There can be reason for making text unselectable. In that case, the property works as designed and does not cause problems. It would not work when document.expando = false, but that would be your fault for setting it. >> See also: >> <URL: http://msdn.microsoft.com/en-us/library/ms534706%28VS.85%29.aspx > >> <URL: http://msdn.microsoft.com/en-us/library/ms533747%28VS.85%29.aspx > > > No thanks! I've wasted enough of my life reading MS' misconceptions. > That documentation provides clarification to expando and unselectable. >>>> | o Host objects that error upon [[Get]] access are often ActiveX >>>> | objects. These include, but are not limited to: >>> Host object _properties_ that throw errors on [[Get]] (a term that is >>> too subterranean for my primers) often indicate that the containing >>> object is an ActiveX implementation. All such method properties do it. >>> >> I am not sure that that is true. For example:- >> >> element.filters.alpha >> >> will result in error in some cases ("Unspecified error", IIRC. > > That is a property of a host object (filters). > >> A quick search indicates that error here: >> http://www.dynamicdrive.com/forums/showthread.php?t=40912 > > There's no need to worry about specific cases if you follow the rules. ;) > >> The OP mentioned that he suspected IE preference "Binary and Script >> Behaviors" disabled as being a possible culprit. > > I can guarantee the OP is using a multi-IE installation. I believe that you can not do that. Those don't > work well with the DirectX interfaces (even Microsoft's own examples > blow up with that error). There's no reason to worry about that as the > multi-IE things are just crawling with bugs. Just so happens we've > discussed that one before with regard to getting opacity (back around > the end of 2007 IIRC). > I have seen such errors on single IE installations. Therefore, it cannot be that the only way to create such errors is to install multiple versions of IE. >> The solution posted there uses CC. Manipulating the filter string is >> sufficient, smaller, simpler, and easier to read (as discussed here). > > That's what we came up with back then (getting/setting the filter > string, but not using CC). > >>>> | + Disconnected nodes whose parentNode is not an element >>>> | (node.offsetParent) >>> In some cases, all properties of element nodes go AWOL ("unknown" typeof >>> results). IIRC, that happens when they are orphaned by an innerHTML >>> replacement. >>> >> I have read of this but have not seen it first hand. > > I see it pop up in larger Web apps from time to time, usually when I > remove an ostensibly unneeded try-catch and find out that the original > authors were shielding themselves from their own mistakes (i.e. catching > an exception that arose due to some unrelated breakdown in logic). > >>>> | + XMLHttpRequest methods (open, send, etc). >>> And its ActiveX equivalents. >>> >>>> | + filters: elem.filters.alpha, elem.style.filters.alpha, etc. >>> The filters object is implemented with ActiveX, so its properties are >>> suspect. >>> >> >>>> | + document.styleSheets[99999] - Error from [[Get]] for a >>>> | nonexistent numeric property of a styleSheets collection. >>> That one may not be due to ActiveX, but just an allowable exception for >>> an out of bounds request. >>> >> I haven't dug deep enough to know, but I would not be surprised if it is >> related to ActiveX. As discussed previously: >> >> javascript: alert(typeof document.styleSheets[9999]) > > What about it? The styleSheets object may be implemented as ActiveX. > Check the typeof results of its methods to find out (will be "unknown"). > What I meant to communicate is that the result of the typeof expression is "unknown". The "unknown" type is believed to be correlated with ActiveX object. [...] >>>> | >>>> | * Type conversion >>>> | [[ToString]] >>>> | Perform string conversion by starting concatenation with a string >>>> | value. See Newsgroup message explanation. >>>> <URL: >>>> http://groups.google.bg/group/comp.lang.javascript/msg/1528f612e31f09fe >>> I don't see how the explanation relates to host objects, which don't >>> have to follow the specs at all. >> The linked newsgroup message shows how string conversion of host object >> does not follow the specification for string conversion. > > I wouldn't expect it to. Such expectations invariably lead to > disappointment. > >> The linked >> message serves as an example of showing that these host objects are >> fragile and can't be trusted. > > Yet another one. > Based on that, I think it's worth keeping in. It is common for beginners to mentally categorize "built-in" and "user-defined" objects, and incorrectly include host objects in the "built-in" category. It can be helpful to understand what a host object is by seeing examples of how host objects behave. >> I would like to finish the entry on "What is a host object", link from >> that, to this "code guidelines" note. >> >> I would also like to mention that when typeof operator results >> "unknown", then the object is unsafe. > > Whatever. You need to add a section to the online resources to link to > some good browser scripting material. DO you think the FAQ needs links to "tutorial" type of pages or do you want the FAQ to link to something you've written added? Either way, if it makes sense to add a link, then it should be added. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |