From: David Mark on
Garrett Smith wrote:
> 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.

>
>>> 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.

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

>
> [...]
>
>>>>> |
>>>>> | * 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?

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?
From: Garrett Smith on
David Mark wrote:
> Garrett Smith wrote:
>> 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.
>
Enough. I could care less of what you have to say.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on
Garrett Smith wrote:
> David Mark wrote:
>> Garrett Smith wrote:
>>> 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.
>>
> Enough. I could care less of what you have to say.

The feeling is mutual (and has been for some time). Your lame stab at
imitation ended up in tears, didn't it?
From: Garrett Smith on
David Mark wrote:
> Garrett Smith wrote:
>> David Mark wrote:
>>> Garrett Smith wrote:
>>>> 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.
>>>
>> Enough. I could care less of what you have to say.
>
> The feeling is mutual (and has been for some time). Your lame stab at
> imitation ended up in tears, didn't it?
I have no idea what that means.

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.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on
Garrett Smith wrote:
> David Mark wrote:
>> Garrett Smith wrote:
>>> David Mark wrote:
>>>> Garrett Smith wrote:
>>>>> 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.
>>>>
>>> Enough. I could care less of what you have to say.
>>
>> The feeling is mutual (and has been for some time). Your lame stab at
>> imitation ended up in tears, didn't it?
> I have no idea what that means.
>
> 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.

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. :)