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+')' });
}
}

[Joshie Surber]

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

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+')' });
}
}

Never played with opacity, but it seems it would work if you did
something like:
el.style.filter = 'alpha(opacity= ' + val * 100 + ')';
el.style.opacit y = val;
el.style['-moz-opacity'] = val;
el.style['-khtml-opacity'] = val;

[Richard Cornford]

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.

<snip>

You should not need to ask this question. The general principle of
feature detection is to devise a test that is as closely related
(preferably directly related) to the question that needs to be answered.
If your question is whether a browser supports IE-style filters then
test for the manifestation of filters; the - filters - collection of the
element:-

if(el.filters){
... //has filters collection.
}

- or the - filters - property of the style object:-

if(typeof el.style.filter s == 'string'){
...//has filters property on style object..
}

(the latter being the most direct test)

Richard.

[petermichaux]

Hi Richard,

Richard Cornford wrote:

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.

<snip>

You should not need to ask this question.

It seems like in the browser scripting world there are always suprises
due to bugs. I don't know about all the bugs. Also the Yahoo! UI guys
do know a thing or two 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')

The general principle of
feature detection is to devise a test that is as closely related
(preferably directly related) to the question that needs to be answered.
If your question is whether a browser supports IE-style filters then
test for the manifestation of filters; the - filters - collection of the
element:-

if(el.filters){
... //has filters collection.
}

- or the - filters - property of the style object:-

if(typeof el.style.filter s == 'string'){
...//has filters property on style object..
}

(the latter being the most direct test)

Richard, you have helped me much in the past months. I do appreciate it
greatly. Due to your persistance, I am currently trying to get myself
off the Yahoo! UI code and also ultimately rid my Rails code of
Prototype.js. I am moving to the layered library approach that you
described previously.

Thank you,
Peter

[Richard Cornford]

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

Richard Cornford wrote:

>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.Active XObject. I also looked at Scriptaculous and
it uses navigator.userA gent.

<snip>

You should not need to ask this question.

It seems like in the browser scripting world there are always
suprises due to bugs. I don't know about all the bugs.

That does not men that most feature detection tests can be directly
deduced from pinning down the question that needs answering.

Also the Yahoo! UI guys
do know a thing or two

Whatever they may know it is not preventing their code form manifesting
non-joined up logic.

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.

<snip>

>if(typeof el.style.filter s == 'string'){

<snip>

This should have been:-

if(typeof el.style.filter == 'string'){

Richard.

[Richard Cornford]

Richard Cornford wrote:

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

<snip>

>It seems like in the browser scripting world there are always
suprises due to bugs. I don't know about all the bugs.

That does not men that most feature detection tests can be
directly deduced from pinning down the question that needs
answering.

<snip>

Should have read:-

"That does not mean that most feature detection tests cannot be
directly
deduced from pinning down the question that needs answering."

Richard.

[Matt Kruse]

Richard Cornford wrote:

"That does not mean that most feature detection tests cannot be
directly deduced from pinning down the question that needs answering."

Most, yes.

But it must be acknowledged that feature-detection is not
behavior-detection.

If a specific browser has a known bug or odd behavior associated with a
feature, simply detecting the feature won't let you fix its faulty behavior.
Although you can write (sometimes complex) code to verify the behavior of a
feature, doing such tests for every feature which might potentially have a
bug in some browser somewhere is wasteful. Sometimes the best way to support
browsers with bugs or quirks is to check for a specific browser in the user
agent string and code accordingly, from WITHIN the proper feature-detection
block.

For example,

if (document.featu re && document.featur e.method) {
if (user agent is Browser 1.5.6.7 on Mac) {
// Do something specific
}
else {
document.featur e.method();
}
}

This way, browser detection will never be executed unless the browser passes
all feature detection tests. If the browser is actually some other browser
with a fake user agent string, it may not pass the feature tests and will
never go into the wrong block to begin with. If it does pass the tests, and
is pretending to be the browser with the bug, then surely the user can
expect code to behave as if they are actually using that browser and deal
with the results.

Alternatively, you could re-define the feature to behave like
standards-compliant browsers so that user agent tests are not required
within the core code at all, and feature detection will work correctly.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Richard Cornford]

Matt Kruse wrote:

Richard Cornford wrote:

>"That does not mean that most feature detection tests cannot be
directly deduced from pinning down the question that needs answering."

Most, yes.

But it must be acknowledged that feature-detection is not
behavior-detection.

Behaviour can be a feature and can often be detected (or worked
around/sidestepped when it cannot).

If a specific browser has a known bug or odd behavior associated with a
feature, simply detecting the feature won't let you fix its faulty behavior.
Although you can write (sometimes complex) code to verify the behavior of a
feature, doing such tests for every feature which might potentially have a
bug in some browser somewhere is wasteful.

How does a known bug in a specific browser become "doing such tests for
every feature which might potentially have a bug in some browser
somewhere"?

Sometimes the best way to support browsers with bugs or
quirks is to check for a specific browser in the user
agent string

No, always the worst thing to do is to start being interested in the
user Agent string. It is not specified as a source of information so
there is no technical foundation for using it as one, and it has
historically been used to mislead software attempting to identify web
browsers so it can be expected to be insufficient for the task.

In all cases where feature detection cannot be applied (and there are
many fewer of those than some people seem to think) object inference
based on a set of features is most likely to give the best indication
on the type of browser.

and code accordingly, from WITHIN the proper feature-detection
block.

For example,

if (document.featu re && document.featur e.method) {
if (user agent is Browser 1.5.6.7 on Mac) {

You can only say "user agent is Browser 1.5.6.7 on Mac" if you can
actually determine that, which you cannot. the best you can say from a
UA string test is that the UA string conforms (in some way) with the
normal/default/expected UA string of "Browser 1.5.6.7 on Mac".

// Do something specific
}
else {
document.featur e.method();
}
}

This way, browser detection will never be executed unless the browser
passes all feature detection tests. If the browser is actually some other
browser with a fake user agent string, it may not pass the feature
tests and will never go into the wrong block to begin with. If it does
pass the tests, and is pretending to be the browser with the bug, then
surely the user can expect code to behave as if they are actually
using that browser and deal with the results.

<snip>

So once again you are blaming the user because a strategy with no
technical foundation results in code that only 'mostly works'.

Richard.

[Matt Kruse]

Richard Cornford wrote:

[snip]
In all cases where feature detection cannot be applied (and there are
many fewer of those than some people seem to think) object inference
based on a set of features is most likely to give the best indication
on the type of browser.

I disagree. Object inference might return the same results between version
1.5 and 1.51 of a browser, but version 1.5 might have a very specific bug in
a feature. If you rely on that feature, and the bug can be "fixed" by code,
then you can use browser sniffing but not object inference. In fact, object
inference fails as time goes on - for example, more browsers supporting
document.all and breaking old scripts which assumed things based on
document.all existing.

You can only say "user agent is Browser 1.5.6.7 on Mac" if you can
actually determine that, which you cannot. the best you can say from a
UA string test is that the UA string conforms (in some way) with the
normal/default/expected UA string of "Browser 1.5.6.7 on Mac".

Within that code, what you're saying is "all my object detection code has
determined that the browser behaves consistently with what I expect of
Browser 1.5.6.7 on Mac, and it's telling me that that's what is is." So
trust it!

Instead, you're suggesting we ignore what it's teling us and the
feature-detection evidence that supports it, and instead look at unrelated
features and guess at whether or not the feature we want is broken. That
seems much more subject to failure.

If a browser has document.all, and supports ActiveX, and claims to be IE6,
then that's a pretty convincing argument. Otherwise, it's someone who is
really trying to mess with things on purpose, and if that's the case then
they probably expect problems. Typical users will probably never have these
kidns of issues.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Richard Cornford]

Matt Kruse wrote:

Richard Cornford wrote:

>[snip]
In all cases where feature detection cannot be applied (and there are
many fewer of those than some people seem to think) object inference
based on a set of features is most likely to give the best indication
on the type of browser.

I disagree. Object inference might return the same results between
version 1.5 and 1.51 of a browser, but version 1.5 might have a very
specific bug in a feature.

But UA strings are nether required to include browser version
information nor are they observed to be accurate in the 'version
information' they do provide".

If you rely on that feature, and the bug can be "fixed" by code,
then you can use browser sniffing but not object inference. In fact, object
inference fails as time goes on - for example, more browsers supporting
document.all and breaking old scripts which assumed things based on
document.all existing.

I was not thinking of half-witted object inference, which would be as
bad as UA string based browser detection. There are almost no single
object from which it would be possible to infer that a browser was a
particular type, but finding a browser that had a large set of features
believed to be unique to a particular browser, and did not have
features common to other browsers but known not to be supported on the
browser in question would be a better indicator that the test subject
was that browser than making deductions from what is no more than a
user-configurable sequence of characters. And in many cases precise
version of browsers can be inferred from a sufficient set of object
tests, as most actual browser development represents a sequence of
additions.

>You can only say "user agent is Browser 1.5.6.7 on Mac" if you can
actually determine that, which you cannot. the best you can say from a
UA string test is that the UA string conforms (in some way) with the
normal/default/expected UA string of "Browser 1.5.6.7 on Mac".

Within that code, what you're saying is "all my object detection code has
determined that the browser behaves consistently with what I expect of
Browser 1.5.6.7 on Mac, and it's telling me that that's what is is." So
trust it!

Was that supposed to mean something?

Instead, you're suggesting we ignore what it's teling us and the
feature-detection evidence that supports it, and instead look at unrelated
features and guess at whether or not the feature we want is broken. That
seems much more subject to failure.

If a browser has document.all, and supports ActiveX, and claims to
be IE6, then that's a pretty convincing argument.

And if a browser has _all_ off; global - ActiveXObject -, - attachEvent
-, - CollectGarbage -, - createPopup -, - ScriptEngine -, -
showModalDialog - and - showModelessDia log - properties that are of
fucntion type, - external -, - onafterprint - and - clientInformati on'
properties of object type, activeElement -, - createStyleShee t -, -
execCommand -, - expando -, - fireEvent -, - onbeforedeactiv ate -, -
onbeforeeditfoc us -, - ondatasetchange d -, - recalc -, - Script - and -
uniqueID - proprties on its document, and - addBehavior -, -
behaviorUrns -, - children -, - currentStyle -, - filters -, -
isContentEditab le -, - oncellchange -, - onerrorupdate -, -
parentElement -, - removeBehavior -, - runtimeStyle - and -
setExpression - prperties on its elements, is reading a UA string that
says "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)" really a more
reliable indicator that the browser is Windows IE 6?

Otherwise, it's someone who is really trying to mess with things
on purpose, and if that's the case then they probably expect problems.

Users are allowed to "mess" with their User Agent strings. If they were
not allowed to then it would not be possible, when it certainly is not
only possible but a direct part of the browser's configuration in some
cases. As the User Agent header/string is not specified as a source of
information they should be no harm in the user changing it (as no
modification could make it mean less then the nothing it is specified
as meaning).

Typical users will probably never have these kidns of issues.

Ah, so user agent string based browser detection 'mostly works', and if
it does not then it's the user's fault?

Richard.