Prev: Google Closure: The Evil Parts
Next: Encapsulation and js, html, css
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