New Host Object Primer
David Mark
detection/testing.
http://www.cinsoft.net/host.html
I think that about sums up the progress (and lack thereof) of the last
few years. You might think Resig is the JS Superman (or Chuck
Norris[1]), but I'm telling you he has a David Mark nightlight. :)
[1] http://benalman.com/news/2009/12/john-resig-javascripts-chuck-norris/
Thomas 'PointedEars' Lahn
> I have posted a new primer related to host objects and feature
> detection/testing.
>
> http://www.cinsoft.net/host.html
>
> I think that about sums up the progress (and lack thereof) of the last
> few years.
ISTM the RegExp is borken:
var reFeaturedMethod = new RegExp('^function|object$', 'i');
It matches case-insensitive either "function" at the begin of input or
"object" at the end, when it should match case-insensitive an input that is
either "function" or "object":
var reFeaturedMethod = new RegExp('^(function|object)$', 'i');
Furthermore, AISB,
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
becomes more efficient when writing
return !!(t == 'unknown' || (reFeaturedMethod.test(t) && o[m]));
The double negation to cast to boolean is a matter of taste; I do not think
it is necessary, because one possible result is a boolean already and the
other has been proven by this that it can be used in a type-converting
test.
Either the identifier or the code of isHostObjectProperty() does not make
sense.
I am going to comment on the rest later.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
David Mark
> David Mark wrote:
>
>> I have posted a new primer related to host objects and feature
>> detection/testing.
>>
>> http://www.cinsoft.net/host.html
>>
>> I think that about sums up the progress (and lack thereof) of the last
>> few years.
>
> ISTM the RegExp is borken:
>
> var reFeaturedMethod = new RegExp('^function|object$', 'i');
>
> It matches case-insensitive either "function" at the begin of input or
> "object" at the end, when it should match case-insensitive an input that is
> either "function" or "object":
You got it. That reflects either sloppiness or cluelessness on my part
at the time I wrote that line (first one I wrote for My Library). :)
it's fixed in the pasted example and the library. Thanks!
And BTW, I forgot to mention your isMethodType as the inspiration for
that function. I'll add that when I have a chance. I need to explain a
little bit more about that one anyway.
>
> var reFeaturedMethod = new RegExp('^(function|object)$', 'i');
>
> Furthermore, AISB,
>
> return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
>
> becomes more efficient when writing
>
> return !!(t == 'unknown' || (reFeaturedMethod.test(t) && o[m]));
Could be. I'm not sure.
>
> The double negation to cast to boolean is a matter of taste; I do not think
> it is necessary, because one possible result is a boolean already and the
> other has been proven by this that it can be used in a type-converting
> test.
I just like for the function to return a boolean for all cases.
>
> Either the identifier or the code of isHostObjectProperty() does not make
> sense.
The identifier is not particularly descriptive. Read the description
carefully. There is an assertion you must make as part of the contract
with that (and isHostMethod). Remember that some objects (e.g.
childNodes) can have typeof "function". You are asserting that you will
do something other than call it, which is why the "unknown" types are
excluded. I need to flesh out the explanation, which was copied
straight from the skeletal library documentation.
>
> I am going to comment on the rest later.
Comments welcome! :)
David Mark
> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>>
>>> I have posted a new primer related to host objects and feature
>>> detection/testing.
>>>
>>> http://www.cinsoft.net/host.html
>>>
>>> I think that about sums up the progress (and lack thereof) of the last
>>> few years.
>> ISTM the RegExp is borken:
>>
>> var reFeaturedMethod = new RegExp('^function|object$', 'i');
>>
>> It matches case-insensitive either "function" at the begin of input or
>> "object" at the end, when it should match case-insensitive an input that is
>> either "function" or "object":
>
> You got it. That reflects either sloppiness or cluelessness on my part
> at the time I wrote that line (first one I wrote for My Library). :)
> it's fixed in the pasted example and the library. Thanks!
>
> And BTW, I forgot to mention your isMethodType as the inspiration for
> that function. I'll add that when I have a chance. I need to explain a
> little bit more about that one anyway.
Now mentioned, as well as the blog post that followed Peter's site.
Garrett Smith
> David Mark wrote:
>
>> I have posted a new primer related to host objects and feature
>> detection/testing.
[...]
>
> ISTM the RegExp is borken:
>
> var reFeaturedMethod = new RegExp('^function|object$', 'i');
>
> It matches case-insensitive either "function" at the begin of input or
> "object" at the end, when it should match case-insensitive an input that is
> either "function" or "object":
>
> var reFeaturedMethod = new RegExp('^(function|object)$', 'i');
>
A Literal would be shorter and would stay cached:
/^(?:func|obj)/;
> Furthermore, AISB,
>
> return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
>
> becomes more efficient when writing
>
> return !!(t == 'unknown' || (reFeaturedMethod.test(t) && o[m]));
>
> The double negation to cast to boolean is a matter of taste; I do not think
> it is necessary, because one possible result is a boolean already and the
> other has been proven by this that it can be used in a type-converting
> test.
>
Double negation on a boolean is pointless. However, `o[m]` should not be
a boolean; it should be a function or an object.
Caveats:
Object `o` could be callable and falsish, such as nonstandard callable
"document.all".
Object `o` could be the `item` method, for which typeof will result
"string" in IE. This would result in isHostMethod returning false.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
Garrett Smith
> 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?
[snip comments about John Resig]
David Mark
> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>>
>>> I have posted a new primer related to host objects and feature
>>> detection/testing.
>
> [...]
>
>>
>> ISTM the RegExp is borken:
>>
>> var reFeaturedMethod = new RegExp('^function|object$', 'i');
>>
>> It matches case-insensitive either "function" at the begin of input or
>> "object" at the end, when it should match case-insensitive an input
>> that is either "function" or "object":
>>
>> var reFeaturedMethod = new RegExp('^(function|object)$', 'i');
>>
>
> A Literal would be shorter and would stay cached:
>
> /^(?:func|obj)/;
I fail to see how that is the same thing, but the non-capturing bit is a
good idea.
As for caching, I don't see how it makes any difference as I create the
RegExp object once.
>
>> Furthermore, AISB,
>>
>> return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
>>
>> becomes more efficient when writing
>>
>> return !!(t == 'unknown' || (reFeaturedMethod.test(t) && o[m]));
>>
>> The double negation to cast to boolean is a matter of taste; I do not
>> think it is necessary, because one possible result is a boolean
>> already and the other has been proven by this that it can be used in a
>> type-converting test.
>>
> Double negation on a boolean is pointless. However, `o[m]` should not be
> a boolean; it should be a function or an object.
Right.
>
> Caveats:
> Object `o` could be callable and falsish, such as nonstandard callable
> "document.all".
>
> 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.
David Mark
> 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?
kangax
> I have posted a new primer related to host objects and feature
> detection/testing.
>
> http://www.cinsoft.net/host.html
Is there a reason `isHostObjectProperty` is not called `isHostProperty`
(to be consistent with `isHostMethod`)?
Also, `findProperietaryStyle` doesn't include "Ms" prefix. Why?
(<http://blogs.msdn.com/ie/archive/2008/09/08/microsoft-css-vendor-extensions.aspx>)
Finally, it might be worth mentioning that `isEventSupported` could (and
_does_, as any other inference) return false positives; from those I
know about — `window`'s "error" in Chrome (present but "defunct"), and
"contextmenu" in Opera 10.50 (even when corresponding option is off in
settings!).
[...]
--
kangax
David Mark
> On 3/23/10 12:52 PM, David Mark wrote:
>> I have posted a new primer related to host objects and feature
>> detection/testing.
>>
>> http://www.cinsoft.net/host.html
>
> Is there a reason `isHostObjectProperty` is not called `isHostProperty`
> (to be consistent with `isHostMethod`)?
The "Object" goes with "Property", not the "Host" part.
>
> Also, `findProperietaryStyle` doesn't include "Ms" prefix. Why?
> (<http://blogs.msdn.com/ie/archive/2008/09/08/microsoft-css-vendor-extensions.aspx>)
Happenstance. It was written before IE8 came out and the sorts of
things I've used it for have had only non-CSS equivalents (e.g. opacity,
transform). I'll add it as they do have a handful of proprietary CSS3
implementations that could be useful to detect (e.g. text-overflow). I
thought I had since added MS for that one in particular, but it may have
been on some other project (I hastily copied the posted implementation
from a My Library add-on).
>
>
> Finally, it might be worth mentioning that `isEventSupported` could (and
> _does_, as any other inference) return false positives; from those I
> know about — `window`'s "error" in Chrome (present but "defunct"), and
> "contextmenu" in Opera 10.50 (even when corresponding option is off in
> settings!).
It is only meant to be used with elements (which I should stipulate of
course). As for "contextmenu", I never considered that a false
positive. The event is supported, but like many things in browsers, the
user has the ability to get in the way. But from your wording, it
sounds as if there is a bug in Opera 10.5 that should be noted (and
reported).
Thanks for the input!
Thomas 'PointedEars' Lahn
> Garrett Smith wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> var reFeaturedMethod = new RegExp('^(function|object)$', 'i');
>>
>> A Literal would be shorter and would stay cached:
>>
>> /^(?:func|obj)/;
>
> I fail to see how that is the same thing, but the non-capturing bit is a
> good idea.
Not if you want this to be backwards-compatible. The Matrix says:
ES JavaScript JScript V8 JSCore Opera KJS
/(?:…)/ : RegExp 3 1.5 5.5.6330 1.3 525.13 7.02 3.5.9
> As for caching, I don't see how it makes any difference as I create the
> RegExp object once.
The question is moot anyway since ES5 implementations instantiate a new
object each time they encounter the literal. (This is different in ES3.)
>>> Furthermore, AISB,
>>>
>>> return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
>>>
>>> becomes more efficient when writing
>>>
>>> return !!(t == 'unknown' || (reFeaturedMethod.test(t) && o[m]));
>>>
>>> The double negation to cast to boolean is a matter of taste; I do not
>>> think it is necessary, because one possible result is a boolean
>>> already and the other has been proven by this that it can be used in a
>>> type-converting test.
>>
>> Double negation on a boolean is pointless.
Yes.
>> However, `o[m]` should not be a boolean; it should be a function or an
>> object.
I beg your pardon?
> Right.
return (t == 'unknown' || (reFeaturedMethod.test(t) && !!o[m]));
But AISB the `!!' does not really save anything as in a boolean context the
return value would be subject to type conversion anyway.
>> 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.
>> 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.
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)
David Mark
> David Mark wrote:
>
>> Garrett Smith wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> var reFeaturedMethod = new RegExp('^(function|object)$', 'i');
>>> A Literal would be shorter and would stay cached:
>>>
>>> /^(?:func|obj)/;
>> I fail to see how that is the same thing, but the non-capturing bit is a
>> good idea.
>
> Not if you want this to be backwards-compatible. The Matrix says:
>
> ES JavaScript JScript V8 JSCore Opera KJS
> /(?:…)/ : RegExp 3 1.5 5.5.6330 1.3 525.13 7.02 3.5.9
I wasn't sure about that, which is why I tend to stick with what I know
for sure. Thanks for illuminating that. Verboten for My Library.
>
>> As for caching, I don't see how it makes any difference as I create the
>> RegExp object once.
>
> The question is moot anyway since ES5 implementations instantiate a new
> object each time they encounter the literal. (This is different in ES3.)
Interesting. What possessed them to do that?
>
>>>> Furthermore, AISB,
>>>>
>>>> return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
>>>>
>>>> becomes more efficient when writing
>>>>
>>>> return !!(t == 'unknown' || (reFeaturedMethod.test(t) && o[m]));
>>>>
>>>> The double negation to cast to boolean is a matter of taste; I do not
>>>> think it is necessary, because one possible result is a boolean
>>>> already and the other has been proven by this that it can be used in a
>>>> type-converting test.
>>> Double negation on a boolean is pointless.
>
> Yes.
>
>>> However, `o[m]` should not be a boolean; it should be a function or an
>>> object.
>
> I beg your pardon?
o[m] will not normally be a boolean, hence the double negation.
>
>> Right.
>
> return (t == 'unknown' || (reFeaturedMethod.test(t) && !!o[m]));
>
> 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.
>
>>> 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.
>
>>> 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.
kangax
> kangax wrote:
>> On 3/23/10 12:52 PM, David Mark wrote:
>>> I have posted a new primer related to host objects and feature
>>> detection/testing.
>>>
>>> http://www.cinsoft.net/host.html
>>
>> Is there a reason `isHostObjectProperty` is not called `isHostProperty`
>> (to be consistent with `isHostMethod`)?
>
> The "Object" goes with "Property", not the "Host" part.
I understand that :) But what does "Property" clarify there? What's
wrong with having `isHostMethod` and `isHostProperty` — where first one
is for testing anything that's intended to be called (i.e. method), and
latter — for anything that won't be called (i.e. property).
[...]
>>
>> Finally, it might be worth mentioning that `isEventSupported` could (and
>> _does_, as any other inference) return false positives; from those I
>> know about — `window`'s "error" in Chrome (present but "defunct"), and
>> "contextmenu" in Opera 10.50 (even when corresponding option is off in
>> settings!).
>
> It is only meant to be used with elements (which I should stipulate of
> course). As for "contextmenu", I never considered that a false
> positive. The event is supported, but like many things in browsers, the
> user has the ability to get in the way. But from your wording, it
> sounds as if there is a bug in Opera 10.5 that should be noted (and
> reported).
Yeah, I should report it to them. The fact that Opera bug tracker is not
open is annoying (I have no idea what's going on with the bugs I filed
in the past).
--
kangax
Garrett Smith
> Garrett Smith wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> David Mark wrote:
>>>
>>>> I have posted a new primer related to host objects and feature
>>>> detection/testing.
>> [...]
>>
>>> ISTM the RegExp is borken:
>>>
>>> var reFeaturedMethod = new RegExp('^function|object$', 'i');
>>>
>>> It matches case-insensitive either "function" at the begin of input or
>>> "object" at the end, when it should match case-insensitive an input
>>> that is either "function" or "object":
>>>
>>> var reFeaturedMethod = new RegExp('^(function|object)$', 'i');
>>>
>> A Literal would be shorter and would stay cached:
>>
>> /^(?:func|obj)/;
>
> I fail to see how that is the same thing, but the non-capturing bit is a
> good idea.
>
Either would do the job as well as:
/^(?:function|object)$/;
Being case-insensitive is pointless, though. I'd ditch the 'i' flag
either way.
> As for caching, I don't see how it makes any difference as I create the
> RegExp object once.
>
The difference would be when the object is created. Either at runtime
(as with constructor) or during lexical scan for regexp literal.
Garrett Smith
I like to see the standard terminology to describe the problems.
I mentioned a few of the problems with host objects here:
http://jibbering.com/faq/notes/code-guidelines/#hostObjects
Posted inline, for convenience:
| Host Objects:
|
| * Operators:
| o Do not use delete operator with host object (IE Errors)
| o Do not add any expando properties (unselectable is safe)
| o Host objects that error upon [[Get]] access are often ActiveX
| objects. These include, but are not limited to:
| + Disconnected nodes whose parentNode is not an element
| (node.offsetParent)
| + XMLHttpRequest methods (open, send, etc).
| + filters: elem.filters.alpha, elem.style.filters.alpha, etc.
| + document.styleSheets[99999] - Error from [[Get]] for a
| nonexistent numeric property of a styleSheets collection.
| + link.href for nntp: links in IE.
| + NodeList in Safari 2 - do not attempt access a nonexistent
| property (e.g. document.childNodes.slice).
|
| * 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 >
Garrett Smith
> On 3/23/10 6:00 PM, David Mark wrote:
>> kangax wrote:
>>> On 3/23/10 12:52 PM, David Mark wrote:
>>>> I have posted a new primer related to host objects and feature
>>>> detection/testing.
[...]
> Yeah, I should report it to them. The fact that Opera bug tracker is not
> open is annoying (I have no idea what's going on with the bugs I filed
> in the past).
>
"Signs point to yes"
(source: magic 8 ball).
Garrett Smith
> 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);
}
That isHostMethod returning something other than false would end up
failing that test. By always returning boolean value, the expectation is
simpler.
>>>> 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.
>>
>>>> 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 [].
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.
David Mark
> On 3/23/10 6:00 PM, David Mark wrote:
>> kangax wrote:
>>> On 3/23/10 12:52 PM, David Mark wrote:
>>>> I have posted a new primer related to host objects and feature
>>>> detection/testing.
>>>>
>>>> http://www.cinsoft.net/host.html
>>>
>>> Is there a reason `isHostObjectProperty` is not called `isHostProperty`
>>> (to be consistent with `isHostMethod`)?
>>
>> The "Object" goes with "Property", not the "Host" part.
>
> I understand that :) But what does "Property" clarify there? What's
> wrong with having `isHostMethod` and `isHostProperty` — where first one
> is for testing anything that's intended to be called (i.e. method), and
> latter — for anything that won't be called (i.e. property).
Because it only tests for object properties (i.e. not booleans, strings,
numbers, etc.)
>
> [...]
>
>>>
>>> Finally, it might be worth mentioning that `isEventSupported` could (and
>>> _does_, as any other inference) return false positives; from those I
>>> know about — `window`'s "error" in Chrome (present but "defunct"), and
>>> "contextmenu" in Opera 10.50 (even when corresponding option is off in
>>> settings!).
>>
>> It is only meant to be used with elements (which I should stipulate of
>> course). As for "contextmenu", I never considered that a false
>> positive. The event is supported, but like many things in browsers, the
>> user has the ability to get in the way. But from your wording, it
>> sounds as if there is a bug in Opera 10.5 that should be noted (and
>> reported).
>
> Yeah, I should report it to them. The fact that Opera bug tracker is not
> open is annoying (I have no idea what's going on with the bugs I filed
> in the past).
>
Yeah, I hope they get that fixed. ISTM, their preferences dialog
sometimes gets out of whack with the reality of the browser window.
Still, I like it and have taken to using it as my primary browser.
David Mark
> David Mark wrote:
>> Garrett Smith wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> David Mark wrote:
>>>>
>>>>> I have posted a new primer related to host objects and feature
>>>>> detection/testing.
>>> [...]
>>>
>>>> ISTM the RegExp is borken:
>>>>
>>>> var reFeaturedMethod = new RegExp('^function|object$', 'i');
>>>>
>>>> It matches case-insensitive either "function" at the begin of input or
>>>> "object" at the end, when it should match case-insensitive an input
>>>> that is either "function" or "object":
>>>>
>>>> var reFeaturedMethod = new RegExp('^(function|object)$', 'i');
>>>>
>>> A Literal would be shorter and would stay cached:
>>>
>>> /^(?:func|obj)/;
>>
>> I fail to see how that is the same thing, but the non-capturing bit is a
>> good idea.
>>
> It is not the same thing.
>
> Either would do the job as well as:
> /^(?:function|object)$/;
I don't want to let anything through that is "func" or "obj". That's a
slippery slope (i.e. why not just test for "fu" and "ob").
>
> Being case-insensitive is pointless, though. I'd ditch the 'i' flag
> either way.
I suppose.
>
>> As for caching, I don't see how it makes any difference as I create the
>> RegExp object once.
>>
>
> The difference would be when the object is created. Either at runtime
> (as with constructor) or during lexical scan for regexp literal.
Right, but I didn't understand what was meant by "caching" as it is a
one-shot deal in either case.
David Mark
> 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
>
> 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?
> | 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.
> | + 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.
> | + 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.
> | + 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.
> |
> | * 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.
David Mark
> 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).
Garrett Smith
> 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 Smith
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.
David Mark
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.
Garrett Smith
> 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.
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.
David Mark
> 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.
I'm not moving it. It won't ever be anything but a static document, so
it doesn't matter.
> 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 don't care (and the users seem fine with it too). :)
>
> I would probably use a URI such as:
>
> http://example.com/articles/host/
>
> [...]
>
> I also do not understand the title:
> "H is for Host"
Have you read the other primers in the series. You'll spot a pattern. ;)
>
> Is this a cookie monster spin-off?
> http://www.youtube.com/watch?v=BovQyphS8kA
No stupid, it's the ABC's of browser scripting.
>
>>>>
>>> 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.
So, basically you've stiffed a lot of guys?
>
>>> 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.
I don't see what that has to do with adding my name.
>
> If somebody wants to create a contributors page -- send me an email or
> post it here and I'll upload it.
I don't think it should be a prerequisite to being listed on the
contributors page.
>
> The FAQ pages are all using the HTML 4.01 strict doctype and validate.
So? Granted, anything else would be lame, but what does it have to do
with this discussion?
>
>>>
>>>>> 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.
Yes, that's the extreme example that we were just talking about.
> 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.
I don't follow.
>
>>> 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.
Well, is it an expando or not (or something in between?)
>
>>> 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.
For me, that sort of trivia is dealt with on a "need to know" basis.
Thus far in my career, I haven't need to know anything about that
distinction.
>
>>>>> | 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.
Sure I can. This is all old news. You can't read opacity (or other
filter data) in multi-IE. It throws inexplicable errors. Using the
filter string property works fine. Nobody should really care though
(multi-IE setups are worthless).
>
> 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.
Of course you can get such errors with any property of an ActiveX object
(and always will with their methods). Looking at the result of the 2007
discussion:-
var m;
// if (html.filters) {
// return function(el) {
// return (typeof el.filters.alpha != 'undefined' &&
el.filters.alpha.enabled)?el.filters.alpha.opacity / 100:1;
// };
// }
return function(el) {
var style = getCascadedStyle(el, 'filter');
if (style) {
m = style.match(reOpacity);
return (m)?parseFloat(m[1]) / 100:1;
}
return 1;
};
})();
...perhaps it is the properties of the alpha object that blow up. I
don't remember and don't really care. I just know that when I see such
errors in my stuff, it is only with multi IE ("library not registered"
or "unspecified error") as I use isHost* (or straight typeof) to detect
everything. The above change was done strictly to make a test work in a
multi-IE setup.
And whatever the OP was doing with CC was definitely unneeded. That I
can say for sure.
> Therefore, it cannot
> be that the only way to create such errors is to install multiple
> versions of IE.
You are generalizing where I was referring to a specific issue.
I know. I am the one that first proposed that idea. That's another
pattern. ;)
http://groups.google.com/group/comp.lang.javascript/msg/67ce68b063909ae7
As I have said (more than once now), the FAQ should have a section of
links related to browser scripting. And yes, I think my series of
primers on the subject should be at the top of that list. What else?
> Either way, if
> it makes sense to add a link, then it should be added.
What does that mean?
Garrett Smith
David Mark
The feeling is mutual (and has been for some time). Your lame stab at
imitation ended up in tears, didn't it?
Garrett Smith
My confusion here probably feels like you did when I wrote:
"MouseEvent.prototype.pageX is a getter in at least one implementation"
- and you can't follow. Except what you wriote was neither technical nor
on-topic, but instead off-topic and emotional.
Trying to have a technical discussion with you is not worthwhile.
Consider that it took re-posting a link to the code guidelines doc (wh,
excepting it, explaining it, then linking to MSDN documentation which
confirms what I was writing all along (and which is fairly common
knowledge to even average javascript developers; apparently not you),
that `unselectable` is an expando.
You vested so much energy into that, when you could have just read the
MSDN docs. Instead, you followed up with:
"Well, is it an expando or not (or something in between?)"
Why am I wasting my time with this? SO I can be told that I am stupid,
blind, hopeless, etc?
Regarding that code guidelines doc, that was, in part, a response to
your phase of posting copy'n'pasted lines of others' code, unformatted,
interspersed with your quips.
David Mark
As usual, you are trying to highlight one irrelevant bit while ignoring
what I was actually responding to.
>
> Trying to have a technical discussion with you is not worthwhile.
That's your opinion and you are welcome to shove it. ;)
> Consider that it took re-posting a link to the code guidelines doc (wh,
> excepting it, explaining it, then linking to MSDN documentation which
> confirms what I was writing all along (and which is fairly common
> knowledge to even average javascript developers; apparently not you),
> that `unselectable` is an expando.
And, as usual, you seek to puff yourself up by highlighting some
obscurity you've memorized. Hint: this stuff is not about memorization;
it's about _thinking_ and solving problems. ;)
>
> You vested so much energy into that, when you could have just read the
> MSDN docs. Instead, you followed up with:
>
> "Well, is it an expando or not (or something in between?)"
So?
>
> Why am I wasting my time with this? SO I can be told that I am stupid,
> blind, hopeless, etc?
Woe is you. :) Perhaps you should think twice before trying to crack wise.
>
> Regarding that code guidelines doc, that was, in part, a response to
> your phase of posting copy'n'pasted lines of others' code, unformatted,
> interspersed with your quips.
Bully for you. :)
johnwlockwood
beginning of the Host Primer.
-John
David Mark
The primers aren't aimed at beginners, but I will add a blurb at the top
with a link for the target audience to skip to the next section.
Thanks for your input!