get opacity value
in [JavaScript]
|
From: Garrett Smith on 21 Nov 2009 01:35 Andrew Poulos wrote: > Thomas 'PointedEars' Lahn wrote: >> Garrett Smith wrote: >> >>> Thomas 'PointedEars' Lahn wrote: >>>> Andrew Poulos wrote: [snip] >>> The latter is being changed now to follow CSS 2.1 Syntax: >>> -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=52)" >>> >>> http://blogs.msdn.com/ie/archive/2008/09/08/microsoft-css-vendor- >> extensions.aspx > > Man, I'm confused. It's a messy situation. SHould I use > -ms-filter:"alpha(opacity=52)" > or > -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=52)" > ? Either for IE8, but for browsers 8 and below, that won't work. The old syntax will: If Microsoft decides to drop the older one, you could use both: -ms-filter:"alpha(opacity=52)"; filter: alpha(opacity=52); The result would be older IE would apply the second filter and IE8 would apply the first and second (which are the same thing), and hypothetical future version of IE would apply the first only. or: -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=52)"; filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=52); Given Microsoft's stance on not supporting invalid syntax, and also because it *is* invalid syntax, it might be better to not use that. > > Anyhow I'm also thinking of using try/catch: Yep. IE produces "unspecified error" when alpha has not been declared in the element's filters. This is a misfortunate tight coupling. To ensure that the error is not produced when reading el.filters.item("alpha"), a try catch is needed. AIUI, the "unspecified error" is an ActiveX error that has propagated back to the script. The MSDN documentation Thomas linked to does not mention that error, though it seems hard to imagine that the person who all of the examples provided there could not have noticed it at some point. He probably did get that error at some point and so I wonder why it was not mentioned there. > > var val; > try { > val = imgRef.filters.item("alpha").opacity; > } catch (err) { > val = 100; > } > > as I'd rather not not use a regexp (no great reason). > That function will fail to read opacity if the CSS uses DXImageTransform. To support both cases, two try/catch would be needed. This is the approach YUI uses: http://developer.yahoo.com/yui/docs/Dom.js.html YUI accesses the filter directly, not using item() method. a.filters['DXImageTransform.Microsoft.Alpha'].opacity. Personally I find that nested try/catch to be much messier than a regexp. It is also going to be less efficient when one or more errors are thrown and caught. A possible strategy would be for your code to only use one of the filter types (the shorter alpha() is an attractive choice). This would eliminate the need for at least one try/catch. Allow both filter types allows little more flexibility in the CSS (less tight coupling of css to script). To make this happen, the script must either: 1) use try/catch for both filter types 2) parse the filter string The first option should be a little slower when one or more errors are thrown. Parsing the currentStyle.filter string with regexp might seem messy, but I find it a bit messier to have the try/catch wrapping it all. If that is not enough, the filters collection is also callable, and the filter string and the Opacity property are all case-insensitive. So the following can work: // This line dedicated to VK. a.filters('dXiMAgeTrAnsfoRM.Microsoft.AlphA').OpAcItY; -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 21 Nov 2009 01:47 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: > > [snip] > > >>> The latter is being changed now to follow CSS 2.1 Syntax: > >>> -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=52)" > > >>>http://blogs.msdn.com/ie/archive/2008/09/08/microsoft-css-vendor- > >> extensions.aspx > > > Man, I'm confused. > > It's a messy situation. > > SHould I use > > > -ms-filter:"alpha(opacity=52)" > > or > > -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=52)" > > ? > > Either for IE8, but for browsers 8 and below, that won't work. The old > syntax will: > > If Microsoft decides to drop the older one, you could use both: > -ms-filter:"alpha(opacity=52)"; > filter: alpha(opacity=52); > > The result would be older IE would apply the second filter and IE8 would > apply the first and second (which are the same thing), and hypothetical > future version of IE would apply the first only. > > or: > > -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=52)"; > filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=52); > > Given Microsoft's stance on not supporting invalid syntax, and also > because it *is* invalid syntax, it might be better to not use that. > > > > > Anyhow I'm also thinking of using try/catch: > > Yep. IE produces "unspecified error" when alpha has not been declared in > the element's filters. This is a misfortunate tight coupling. > > To ensure that the error is not produced when reading > el.filters.item("alpha"), a try catch is needed. No. Use isHostObjectProperty (which uses typeof). It's another "unknown" type as it is an ActiveX property. Inexplicably, I have a raw typeof test in mine. I had commented out the bogus filters collection based branch in the setter years ago, but never updated the getter. It should have been using isHostObjectProperty, which disallows 'unknown' types. It's a rare case that this method is needed outside of feature detection. Or you could just inline the test as it is simple, but I like having it centralized in case MS (or somebody else) introduces a new type of trouble.
From: David Mark on 21 Nov 2009 02:11 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: > > > [snip] > > > >>> The latter is being changed now to follow CSS 2.1 Syntax: > > >>> -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=52)" > > > >>>http://blogs.msdn.com/ie/archive/2008/09/08/microsoft-css-vendor- > > >> extensions.aspx > > > > Man, I'm confused. > > > It's a messy situation. > > > SHould I use > > > > -ms-filter:"alpha(opacity=52)" > > > or > > > -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=52)" > > > ? > > > Either for IE8, but for browsers 8 and below, that won't work. The old > > syntax will: > > > If Microsoft decides to drop the older one, you could use both: > > -ms-filter:"alpha(opacity=52)"; > > filter: alpha(opacity=52); > > > The result would be older IE would apply the second filter and IE8 would > > apply the first and second (which are the same thing), and hypothetical > > future version of IE would apply the first only. > > > or: > > > -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=52)"; > > filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=52); > > > Given Microsoft's stance on not supporting invalid syntax, and also > > because it *is* invalid syntax, it might be better to not use that. > > > > Anyhow I'm also thinking of using try/catch: > > > Yep. IE produces "unspecified error" when alpha has not been declared in > > the element's filters. This is a misfortunate tight coupling. > > > To ensure that the error is not produced when reading > > el.filters.item("alpha"), a try catch is needed. > > No. Use isHostObjectProperty (which uses typeof). It's another > "unknown" type as it is an ActiveX property. > > Inexplicably, I have a raw typeof test in mine. I had commented out > the bogus filters collection based branch in the setter years ago, but > never updated the getter. It should have been using > isHostObjectProperty, which disallows 'unknown' types. It's a rare > case that this method is needed outside of feature detection. Or you > could just inline the test as it is simple, but I like having it > centralized in case MS (or somebody else) introduces a new type of > trouble. 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. 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).
From: Thomas 'PointedEars' Lahn on 21 Nov 2009 05:40 Garrett Smith wrote: > Andrew Poulos wrote: >> Thomas 'PointedEars' Lahn wrote: >>> Garrett Smith wrote: >>>> Thomas 'PointedEars' Lahn wrote: >>>>> Andrew Poulos wrote: >>>> The latter is being changed now to follow CSS 2.1 Syntax: >>>> -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=52)" >>>> >>>> http://blogs.msdn.com/ie/archive/2008/09/08/microsoft-css-vendor- >>> extensions.aspx >> Man, I'm confused. > > It's a messy situation. Nonsense. The problem is only in your head. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: Thomas 'PointedEars' Lahn on 21 Nov 2009 05:45 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. > 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. 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.)
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Google Closure: The Evil Parts Next: Encapsulation and js, html, css |