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?
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.
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.
That's everyone's term for properties that augment host objects.
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.
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.
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).
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).
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.
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.
