From: David Mark on 21 Nov 2009 05:50 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 21 Nov 2009 05:57 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 21 Nov 2009 06:13 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 21 Nov 2009 07:50 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 21 Nov 2009 19:26 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/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Google Closure: The Evil Parts Next: Encapsulation and js, html, css |