Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Cross-browser setOpacity() without browser sniffing?

Reply
Thread Tools

Cross-browser setOpacity() without browser sniffing?

 
 
petermichaux@gmail.com
Guest
Posts: n/a
 
      09-05-2006
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.ActiveXObject && 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
incompatibilities and bugs and all the programmer incompatibilities and
bugs too.

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

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

- Peter

 
Reply With Quote
 
 
 
 
VK
Guest
Posts: n/a
 
      09-06-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) 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.ActiveXObject. I also looked at Scriptaculous
> and it uses navigator.userAgent.


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.someMethodOrProperty == '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.

 
Reply With Quote
 
 
 
 
Richard Cornford
Guest
Posts: n/a
 
      09-06-2006
(E-Mail Removed) 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.ActiveXObject && 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
> incompatibilities and bugs and all the programmer
> incompatibilities 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.com/group/ydn-javascript/message/4585>
>
> So it looks like I can safely drop the "window.ActiveXObject &&"
> part of the conditional.


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

Richard.


 
Reply With Quote
 
petermichaux@gmail.com
Guest
Posts: n/a
 
      09-06-2006
Richard Cornford wrote:
> (E-Mail Removed) 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.ActiveXObject && 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

 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      09-07-2006
(E-Mail Removed) wrote:
> Richard Cornford wrote:
>> (E-Mail Removed) 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.


 
Reply With Quote
 
petermichaux@gmail.com
Guest
Posts: n/a
 
      09-07-2006
Hi Richard,

Richard Cornford wrote:
> (E-Mail Removed) wrote:
> > Richard Cornford wrote:
> >> (E-Mail Removed) 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

 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      09-07-2006
(E-Mail Removed) 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.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Try this Latest Firefox browser at http://browser.friendsrus.net subs2me@gmail.com Firefox 9 12-28-2005 09:20 AM
Re: Browser plug-in to interact with browser DKM Java 15 06-12-2005 02:11 AM
Browser information not being sent to the Domain Master Browser Russell Stamper Cisco 1 10-12-2004 08:14 PM
Avant browser and MyIE2 browser becoming increasingly popular. Issues? xyZed HTML 9 05-12-2004 09:50 AM
Browser levels, PDAs and browser sniffing Lauchlan M ASP .Net 2 08-17-2003 04:58 PM



Advertisments