Cross-browser setOpacity() without browser sniffing?

[petermichaux]

Hi,

Does anyone have a a cross-browser setOpacity function that does not
use browser sniffing? I looked at the Yahoo! UI function and it detects
IE by looking for window.ActiveXO bject. I also looked at Scriptaculous
and it uses navigator.userA gent.

Thanks,
Peter
Roughly the Yahoo! UI bit of relavent code

var el = document.getEle mentById('foo') ;

if (window.ActiveX Object && typeof el.style.filter == 'string') { //
in case not appended
el.style.filter = 'alpha(opacity= ' + val * 100 + ')';

if (!el.currentSty le || !el.currentStyl e.hasLayout) {
el.style.zoom = 1; // when no layout or cant tell
}
} else {
el.style.opacit y = val;
el.style['-moz-opacity'] = val;
el.style['-khtml-opacity'] = val;
}

The bit of Scriptaculous code

Element.setOpac ity = function(elemen t, value){
element= $(element);
if (value == 1){
Element.setStyl e(element, { opacity:
(/Gecko/.test(navigator .userAgent) &&
!/Konqueror|Safar i|KHTML/.test(navigator .userAgent)) ?
0.999999 : null });
if(/MSIE/.test(navigator .userAgent))
Element.setStyl e(element, {filter:
Element.getStyl e(element,'filt er').replace(/alpha\([^\)]*\)/gi,'')});
} else {
if(value < 0.00001) value = 0;
Element.setStyl e(element, {opacity: value});
if(/MSIE/.test(navigator .userAgent))
Element.setStyl e(element,
{ filter:
Element.getStyl e(element,'filt er').replace(/alpha\([^\)]*\)/gi,'') +
'alpha(opacity= '+value*100+')' });
}
}

[petermichaux]

Richard Cornford wrote:

>

and the fact that they double up with the
following two checks makes me wonder if something
else is going on.

if (window.ActiveX Object && typeof el.style.filter == 'string')

Voodoo. Too many browsers have a global ActiveXObjet constructor (real
or object inference defeating dummy) for testing it in any context other
than a desire to instantiate an ActiveX object to be rational.

I asked about this on the Yahoo! UI group as well. The author of the
code seems very friendly and responded that it was a bit of defensive
coding because of the audience they are targeting with their YUI
scripts. Interesting reasoning and I imagine writing library scripts
for widespread use is quite challenging: all the browser
incompatibiliti es and bugs and all the programmer incompatibiliti es and
bugs too.

<URL: http://groups.yahoo.co m/group/ydn-javascript/message/4585>

So it looks like I can safely drop the "window.ActiveX Object &&" part
of the conditional.

- Peter

[VK]

pe**********@gm ail.com wrote:

Does anyone have a a cross-browser setOpacity function that does not
use browser sniffing? I looked at the Yahoo! UI function and it detects
IE by looking for window.ActiveXO bject. I also looked at Scriptaculous
and it uses navigator.userA gent.

That is close related to your other question about Safari 1.x feature
test.
The "pure feature detection" is only possible for the ideal situations
where either the feature is presented and it works as documented across
all UA's with such feature - or the feature is not presented which is
easy to detect by say
if (typeof someObject.some MethodOrPropert y == 'undefined')
or similar.

But as you are forced to act in the imperfect real word, the above
situation will be a rare exception rather than a rule.
Most of the time you have the twilight situation then the feature is
"presented" but
1) it is not actually implemented. It is just a loophole to say True to
trick possible feature tests. Many wannabes (especially older ones) are
bad on it.
or
2) it is implemented but the implementation is broken and requires
extra procedure to compensate the failure.
or
3) it is implemented but in the way UA's producers decided to go, not
in the standard way.

Say Safari 1.x generously covers the situations 2) and 3) and this
"coverage" differs dramatically from one minor version to another. So
say to really deal with Safari 1.x, a simple browsing sniffing is not
enough - you also have to sniff the version.

In the relevance to the opacity and IE: the ActiveXObject feature test
is not relevant to the opacity as IE's filters are not activated over
new ActiveXObject() .
It must be a general combo test to branch onto IE-specific procedures
and workarounds.

[Richard Cornford]

pe**********@gm ail.com wrote:

Richard Cornford wrote:

>>and the fact that they double up with the
following two checks makes me wonder if something
else is going on.

if (window.ActiveX Object && typeof el.style.filter == 'string')

Voodoo. Too many browsers have a global ActiveXObjet constructor
(real or object inference defeating dummy) for testing it in any
context other than a desire to instantiate an ActiveX object to
be rational.

I asked about this on the Yahoo! UI group as well. The author of
the code seems very friendly and responded that it was a bit of
defensive coding because of the audience they are targeting with
their YUI scripts.

As I said, it is voodoo. Of the browsers that I know have a global -
ActiveXObject - constructor only Winnows IE 5+ actually supports
filters. Preceding a test for the - filter - string on the - style -
object with a test that will not even pin the browser down to a
Microsoft product is just pointless.

Interesting reasoning

Hardly reasoning at all. You notice the author cannot be specific about
which browsers have which issues. It is just an excuse for doing
something that had no basis in reason in the first palce.

and I imagine writing library scripts
for widespread use is quite challenging: all the browser
incompatibiliti es and bugs and all the programmer
incompatibiliti es and bugs too.

Particularly challenging without a good grasp of javascript or a broad
experience of actual web browsers (both of which are evident in the
faults in the code).

<URL: http://groups.yahoo.co m/group/ydn-javascript/message/4585>

So it looks like I can safely drop the "window.ActiveX Object &&"
part of the conditional.

It should never have been included in the first place; it was pure
voodoo.

Richard.

[petermichaux]

Richard Cornford wrote:

pe**********@gm ail.com wrote:

Richard Cornford wrote:

>and the fact that they double up with the
following two checks makes me wonder if something
else is going on.

if (window.ActiveX Object && typeof el.style.filter == 'string')

Voodoo. Too many browsers have a global ActiveXObjet constructor
(real or object inference defeating dummy) for testing it in any
context other than a desire to instantiate an ActiveX object to
be rational.

I asked about this on the Yahoo! UI group as well. The author of
the code seems very friendly and responded that it was a bit of
defensive coding because of the audience they are targeting with
their YUI scripts.

As I said, it is voodoo. Of the browsers that I know have a global -
ActiveXObject - constructor only Winnows IE 5+ actually supports
filters. Preceding a test for the - filter - string on the - style -
object with a test that will not even pin the browser down to a
Microsoft product is just pointless.

Interesting reasoning

Hardly reasoning at all. You notice the author cannot be specific about
which browsers have which issues. It is just an excuse for doing
something that had no basis in reason in the first palce.

I think the reasoning makes sense for the Yahoo! UI audience. The
Yahoo! UI is integrated with legacy scripts which may assign directly
to style.filter without first checking it's existance. So for the
browsers that don't have ActiveXObject the YUI setOpacity() function
will still work. The check for ActiveXObject rescues the functionality
of setOpacity() in at least some of the browsers.

I suppose you could argue that they should let the functionality break
in those cases as an indicator that the legacy JavaScript should be
modified. I guess they didn't want to do that.

Peter

[Richard Cornford]

pe**********@gm ail.com wrote:

Richard Cornford wrote:

>pe**********@gm ail.com wrote:

<snip>

>>Interesting reasoning

Hardly reasoning at all. You notice the author cannot
be specific about which browsers have which issues. It
is just an excuse for doing something that had no basis
in reason in the first palce.

I think the reasoning makes sense for the Yahoo! UI audience.
The Yahoo! UI is integrated with legacy scripts which may
assign directly to style.filter without first checking it's
existance. So for the browsers that don't have ActiveXObject
the YUI setOpacity() function will still work. The check for
ActiveXObject rescues the functionality of setOpacity() in
at least some of the browsers.

That sounds like someone casting around for any excuse for doing
something when they have realised that they should not have been doing
it in the first place. But even if the true reasoning behind the
'decision' it is a poor approach.

It would be enough to observe that in browser supporting -
style.filter - the TITLE element is accessible, has a - style - object
and that object has a testable - filter - property that is a string. It
would be insane for anyone to directly set a filter on an element that
has no visible manifestation in a page so testing that property may be
the test closet to the issue where the possibility of other scripts
assigning to - style.filter - exists.

It is the mindset that thinks resorting to hit and miss browser sniffing
is an option that should be considered that keeps people from trying to
pin down their problem to the point where a direct feature test is
obvious.

I suppose you could argue that they should let the
functionality break in those cases as an indicator that
the legacy JavaScript should be modified. I guess they
didn't want to do that.

It might be better argued that if a browser has downloaded one mechanism
for assigning to - filter - it should using only that and not be
downloading two. That is exactly the sort of bloat due to needless
repetition that is an argument against monolithic general purpose
libraries as a concept in javascript.

On the other hand I suppose there is a possibility that a separate
sub-system may have been assigning other filters (say drop-shadows), but
then the Yahoo opacity mechanism would screw that up anyway by wiping
the other filter as it assigned its opacity filter. So the though
process that supposedly considered the behaviour of other scripts was
not actually carried through to an appreciation of all the applicable
possibilities.

Richard.

[petermichaux]

Hi Richard,

Richard Cornford wrote:

pe**********@gm ail.com wrote:

Richard Cornford wrote:

pe**********@gm ail.com wrote:

<snip>

>Interesting reasoning

Hardly reasoning at all. You notice the author cannot
be specific about which browsers have which issues. It
is just an excuse for doing something that had no basis
in reason in the first palce.

I think the reasoning makes sense for the Yahoo! UI audience.
The Yahoo! UI is integrated with legacy scripts which may
assign directly to style.filter without first checking it's
existance. So for the browsers that don't have ActiveXObject
the YUI setOpacity() function will still work. The check for
ActiveXObject rescues the functionality of setOpacity() in
at least some of the browsers.

That sounds like someone casting around for any excuse for doing
something when they have realised that they should not have been doing
it in the first place. But even if the true reasoning behind the
'decision' it is a poor approach.

It would be enough to observe that in browser supporting -
style.filter - the TITLE element is accessible, has a - style - object
and that object has a testable - filter - property that is a string. It
would be insane for anyone to directly set a filter on an element that
has no visible manifestation in a page so testing that property may be
the test closet to the issue where the possibility of other scripts
assigning to - style.filter - exists.

Great solution. Of course I didn't know about that trick. Where is the
list of all these feature tests?

I doubt they thought of that test but perhaps some documents they are
considering don't even have a title element.

It is the mindset that thinks resorting to hit and miss browser sniffing
is an option that should be considered that keeps people from trying to
pin down their problem to the point where a direct feature test is
obvious.

I suppose you could argue that they should let the
functionality break in those cases as an indicator that
the legacy JavaScript should be modified. I guess they
didn't want to do that.

It might be better argued that if a browser has downloaded one mechanism
for assigning to - filter - it should using only that and not be
downloading two. That is exactly the sort of bloat due to needless
repetition that is an argument against monolithic general purpose
libraries as a concept in javascript.

On the other hand I suppose there is a possibility that a separate
sub-system may have been assigning other filters (say drop-shadows), but
then the Yahoo opacity mechanism would screw that up anyway by wiping
the other filter as it assigned its opacity filter.

I mentioned this to the author and he wants to change this eventually.
They are actually quite interested in the thoughts of others and want
the library to be good. I think they might be developing under time
pressure and not be able to revist the code they want to.

Peter

[Richard Cornford]

pe**********@gm ail.com wrote:

Richard Cornford wrote:

<snip>

>It would be enough to observe that in browser supporting -
style.filter - ...

Great solution. Of course I didn't know about that trick.
Where is the list of all these feature tests?

There is (and could never be) a list of feature detection tests. Feature
detection is a strategy with a method; you analyse the problem to pin
down the question that needs to be answered and the test that answers
that question in the most direct way (preferably with a one-to-one
relationship to the issue) will then usually be obvious. So, you want to
know when applying - style.filters - is meaningful so you test for
manifestations of - style.filters -, and you also want to put up other
scripts writing to - style.filters - on arbitrary elements so you test
the feature on an element that nobody (sane) would assign a filter to.

I doubt they thought of that test

So do I, but I think that they failed to think of that test because
instead of learning to do browser scripting well they have decided to
hide behind browser sniffing and 'mostly works'.

but perhaps some documents they are
considering don't even have a title element.

The TITLE element is the only element that is _required_ in a valid HTML
document. And they are error-corrected into existence if omitted on
actual browsers (including IE).

<snip>

>On the other hand I suppose there is a possibility that a
separate sub-system may have been assigning other filters
(say drop-shadows), but then the Yahoo opacity mechanism
would screw that up anyway by wiping the other filter as it
assigned its opacity filter.

I mentioned this to the author and he wants to change this
eventually.

So I was correct in assuming that he had not thought through the issues
he was claiming to be acting to mitigate.

They are actually quite interested in the thoughts of others
and want the library to be good.

Even if the thoughts of others are that the style of library manifest is
inappropriate for browser scripting and so can never be 'good'? I think
Yahoo's libraries are in fact only a self-promotion exercise leveraged
off work they would otherwise have to do for themselves internally, so
the only actual intention is to avoid being subject to criticism for
creating faulty code.

Remember that because yahoo use 100% of their code themselves for them
it is an application specific framework not a general purpose library.

I think they might be developing under time
pressure and not be able to revist the code they want to.

Or it already does what Yahoo want it to do internally so additional
development is only worthwhile when it is to remove obvious subjects for
the criticism that would diminish its potential as a (cheep) promotional
exercise.

Richard.