From: David Mark on
On Nov 21, 5:45 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> David Mark wrote:
> > 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
>
> If it is `unknown', your test would produce a false positive.
>
> > That's where isHostObjectProperty comes in handy as you don't have to
> > think about this stuff.
>
> As long as it handles this case.

It certainly does.

>
> > So you could test:-
>
> > typeof el.filters.alpha != 'undefined' && el.filters.alpha.enabled
> > && ...
>
> ACK
>
> > But not:
>
> > typeof el.filters.alpha != 'undefined' && el.filters.alpha &&
> > el.filters.alpha.enable && ...
>
> ACK
>
> > 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).
>
> Nonsense.
>

There you go again. It is certainly not nonsense. It is far more
robust as IE5.x has problems when dealing with the filters
collection. Granted, I've only ever seen it on XP in a multi-IE
setup, but that setup was otherwise reliable AFAIK. And I would
prefer not to break if and when MS drops support for the old-style
alpha(opacity=...) style which was deprecated by MS in IE5.5.
From: David Mark on
On Nov 21, 5:50 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> On Nov 21, 5:45 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
> wrote:
>
> > David Mark wrote:
> > > 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
>
> > If it is `unknown', your test would produce a false positive.
>
> > > That's where isHostObjectProperty comes in handy as you don't have to
> > > think about this stuff.
>
> > As long as it handles this case.
>
> It certainly does.
>

Thinking again, I had it right to begin with. I should _not_ have
used isHostObjectProperty for that as I did not type convert the
object referenced by the alpha property. All I needed to know in that
case was whether it was undefined. But I still don't like messing
with the filters collection in a GP library. Seems inefficient to
check for both styles in this way (certainly either must be allowed).
From: David Mark on
On Nov 21, 5:50 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> On Nov 21, 5:45 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
> wrote:
>
> > David Mark wrote:
> > > 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
>
> > If it is `unknown', your test would produce a false positive.
>
> > > That's where isHostObjectProperty comes in handy as you don't have to
> > > think about this stuff.
>
> > As long as it handles this case.
>
> It certainly does.
>
>
>
>
>
> > > So you could test:-
>
> > > typeof el.filters.alpha != 'undefined' && el.filters.alpha.enabled
> > > && ...
>
> > ACK
>
> > > But not:
>
> > > typeof el.filters.alpha != 'undefined' && el.filters.alpha &&
> > > el.filters.alpha.enable && ...
>
> > ACK
>
> > > 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).
>
> > Nonsense.
>
> There you go again.  It is certainly not nonsense.  It is far more
> robust as IE5.x has problems when dealing with the filters
> collection.  Granted, I've only ever seen it on XP in a multi-IE
> setup, but that setup was otherwise reliable AFAIK.  And I would
> prefer not to break if and when MS drops support for the old-style
> alpha(opacity=...) style which was deprecated by MS in IE5.5.

Correction: when and if they drop support for the filter style. As
for dropping alpha(opacity=...), I wouldn't put it past them and don't
care about IE4 anymore, so I think I would favor that today.

And I saw your comment about IE tester. I don't think that's the one
I had, but it could have had DLL mismatch problems. I suppose that
doesn't really matter. We had this discussion back during the Code
Worth Recommending suggestion period.
From: Thomas 'PointedEars' Lahn on
David Mark wrote:

> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>> > 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).
>> Nonsense.
>
> There you go again. It is certainly not nonsense.

Yes, it is. There is only one "CSS" property declaration necessary, and the
results of that declaration are much more easily feature-tested than parsed.

> It is far more robust as IE5.x has problems when dealing with the filters
> collection.

I stand corrected in that accessing `filters' is apparently not possible in
*Standalone* IE 5.0 and 5.5 (tested on Wine). However, I must be very much
mistaken if <http://PointedEars.de/ufpdb/> broke as I wrote it back in 2000
(it uses the blendTrans filter to blend-out the UFP logo after a while).
Unfortunately, a real IE 5.x is hard to come by these days.

> [...] I would prefer not to break if and when MS drops support for the
> old-style alpha(opacity=...) style which was deprecated by MS in IE5.5.

`opacity' can take over almost seamlessly then; all it takes is changing

<!--[if IE]>...<![endif]-->

into

<!--[if IE lt $VERSION]>...<![endif]-->

Or, if you are a precog, you could write

<!--[if IE lte 8]>...<![endif]-->

in the first place ;-)


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Garrett Smith on
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?

> 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"];

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

Typeconverting, etc, and I do not get an error in my test page:

if(el.filters["alpha"]) { /*no error?*/ }

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");

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

What is the condition where either (1) or (2) give errors? It is hard to
justify a workaround I when I cannot reproduce the error. Need to know
exactly where and what causes that error.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/