Prev: Google Closure: The Evil Parts
Next: Encapsulation and js, html, css
From: David Mark on 21 Nov 2009 19:44
On Nov 21, 7:26 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> David Mark wrote:
> > On Nov 21, 1:47 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> >> On Nov 21, 1:35 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>
> >>> Andrew Poulos wrote:
> >>>> Thomas 'PointedEars' Lahn wrote:
> >>>>> Garrett Smith wrote:
> >>>>>> Thomas 'PointedEars' Lahn wrote:
> >>>>>>> Andrew Poulos wrote:
>
> [snips]
>
> > Trying it in IE8, this does appear sufficient:-
>
> > typeof el.filters.alpha != 'undefined'
>
> > If it isn't there, it is 'undefined', if it is, I am sure it is
> > "unknown", so you shouldn't type convert it.  That's where
> > isHostObjectProperty comes in handy as you don't have to think about
> > this stuff.
>
> I am not sure. I am getting "object" in IETester. Is this IETester
> related result?

If you get "object", it shouldn't blow up. But regardless, see that
function I posted for the basic logic that should work every time
without fear of explosions.

>
> > So you could test:-
>
> > typeof el.filters.alpha != 'undefined' && el.filters.alpha.enabled
> > && ...
>
> > But not:
>
> > typeof el.filters.alpha != 'undefined' && el.filters.alpha &&
> > el.filters.alpha.enable && ...
>
> > Of course, the first one leaves out the possibility that
> > el.filters.alpha is null (something isHostObjectProperty handles as
> > well).  And, as mentioned, it is best to leave the filters collection
> > alone and use a RegExp on the serialization (filter style).
>
> I have noticed an occasional "unknown error" with either of:
> 1)  el.filters.alpha
> 2)  el.filters["progid:DXImageTransform.Microsoft.Alpha"];

That's when they are "unknown" types. Remember IE changes host object
types sometimes (e.g. element nodes orphaned by innerHTML). From
"object" to "unknown" seems to indicate a shift in the implementation
behind the scenes to an ActiveX object. God only knows why they would
do it, but it is their right as browser developers. As has always
been the case with MSHTML (and everything else AFAIK), typeof lets you
"peek" without triggering an exception.

>
> The error does not always occur. I have never understood why it occurs
> sometimes and other times it does not.

I never tried to understand such things. :)

>
> Typeconverting, etc, and I do not get an error in my test page:
>
> if(el.filters["alpha"]) { /*no error?*/ }

You would for sure if that filter object was an "unknown" type.

>
> I remember getting errors from that before and I see in YUI the
> try/catch, plus a comment.http://developer.yahoo.com/yui/docs/Dom.js.html
> (search for "opacity");

YUI doesn't know how to feature test MSHTML. Odd considering how many
times this has come up over the years (and that the behavior is
unchanged since at least IE6).

>
> Avoiding that error is my reason for using the currentStyle.filter
> string. That has never given me errors.

It won't. It's definitely the most robust approach, but because of
the ActiveX nonsense. Some multi-IE setups won't handle the filters
collection. First time I saw that on XP, I wondered how my (then)
eight-year old DX code could have broken. Then I went to the MSDN
filter and transitions demo page and saw the same thing. So it is
probably a DLL mixup.

>
> What is the condition where either (1) or (2) give errors?

Properties of ActiveX (unknown type) throw errors on type conversion,
assignment to a variable, etc. You really can't do anything to or
with them directly (other than the typeof operation). It's been
floated that a rigged internal [[Get]] is to blame. But who really
knows? The main thing to know is that they all behave exactly the
same.

> It is hard to
> justify a workaround I when I cannot reproduce the error. Need to know
> exactly where and what causes that error.

I thought you were getting errors at some point. (?) See that last
function. It's a slight modification of isHostObjectProperty.
From: Garrett Smith on 21 Nov 2009 20:44
David Mark wrote:
> On Nov 21, 7:26 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 21, 1:47 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>>>> On Nov 21, 1:35 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>>>>> Andrew Poulos wrote:
>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>> Garrett Smith wrote:
>>>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>>>> Andrew Poulos wrote:

[snips]

[snip explanation]

That seems to explain it.

>
>> It is hard to
>> justify a workaround I when I cannot reproduce the error. Need to know
>> exactly where and what causes that error.
>
> I thought you were getting errors at some point. (?) See that last
> function. It's a slight modification of isHostObjectProperty.

I was getting errors at some point.

The last example I made did not exhibit the error. Out of curiosity, I
want to know the exact circumstances that can reproduce this error.

I see now that it's a "behind the scenes" type of thing. The code behind
the filters is likely as bizarre and complex as the filters interface,
but I still wonder about the conditions it occurs under.

Regexing the currentStyle.filters string has not let me down, and avoids
the problem, so I will continue as I have been doing. I just wonder
about when the unknown error occurs.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 21 Nov 2009 21:21
On Nov 21, 8:44 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> David Mark wrote:
> > On Nov 21, 7:26 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> >> David Mark wrote:
> >>> On Nov 21, 1:47 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> >>>> On Nov 21, 1:35 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> >>>>> Andrew Poulos wrote:
> >>>>>> Thomas 'PointedEars' Lahn wrote:
> >>>>>>> Garrett Smith wrote:
> >>>>>>>> Thomas 'PointedEars' Lahn wrote:
> >>>>>>>>> Andrew Poulos wrote:
>
> [snips]
>
> [snip explanation]
>
> That seems to explain it.
>
>
>
> >> It is hard to
> >> justify a workaround I when I cannot reproduce the error. Need to know
> >> exactly where and what causes that error.
>
> > I thought you were getting errors at some point. (?)  See that last
> > function.  It's a slight modification of isHostObjectProperty.
>
> I was getting errors at some point.

I assume you mean the errors induced by looking too closely at the
object referenced by an ActiveX property (typeof xyz == 'unknown').

>
> The last example I made did not exhibit the error. Out of curiosity, I
> want to know the exact circumstances that can reproduce this error.

I haven't considered it (and prefer not to), but I'll take a wild stab
in the dark and say that the deprecated alpha filter syntax produces a
"normal" host object, which is reported by the browser as an "object"
type. Perhaps the new style results in an ActiveX object ("unknown"
type) behind the scenes? You might try it out if you really want to
know, but I would use a real IE installation.

But best to cover both bases (as the suggested function does). And
ultimately faster to cover both bases with the (string) filter
property. The worst possibility would be testing filters with nested
try-catch clauses, which is both brittle (e.g. IE < 6 on XP) and slow.

>
> I see now that it's a "behind the scenes" type of thing. The code behind
> the filters is likely as bizarre and complex as the filters interface,
> but I still wonder about the conditions it occurs under.

I'm sure it is a mess behind the scenes.

>
> Regexing the currentStyle.filters string has not let me down, and avoids
> the problem, so I will continue as I have been doing. I just wonder
> about when the unknown error occurs.

I'm sure you meant the currentStyle.filter string.
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Google Closure: The Evil Parts
Next: Encapsulation and js, html, css