"Feature detection is all about new and unknown browsers - hoping that
your code will continue to persist. You conflate it with supporting
old browsers that are lacking features - which is a completely
separate set of discussions."
"You're worried about old browsers failing gracefully - and that's a
completely different set of issues from what normal bug fix feature
detection should be handling."
Thank you, John, for summarizing the seeming confusion on this topic -
forward-looking VS legacy issues.
This discussion was never about "which is better", browser or feature
detection. The issue was whether there is *EVER* a proper use for
browser-detection. If there is even a single instance where it is
necessary or beneficial with no downside, then the fact is that
browser detection remains a useful tool to have on hand.
For *forward-looking compatibility*, feature-detection is clearly the
way to go - I don't see anyone in this thread disagreeing with this.
But when dealing with *legacy browsers* - IE6 & IE7/quirksmode in
particular - it is often easier (and more reliable) to use browser
detection instead. The idiocyncrisies of IE6 are well documented, so
in my opinion, creating feature-detection 'hacks' serves no purpose
other than being an interesting exercise. Unless someone can tell me
another browser that does box-models *exactly* like IE6/7-qm, or a
browser other than IE that requires bgIframe for SELECT fields, then I
rest my case.
Hopefully, when these old browsers are retired, the need for browser-
detection and similar bug-detection may disappear. Until then, IE6/7
still holds a dominant place in the market, and therefore often
deserves special handling. Personally, I don't to waste ms when I
don't have to, so I will continue to optimize for legacy IE browsers
and sites (when writing plugins) by using $.browser when it seems the
best and simplest option. Others can make their own choices.
/Kevin
On Jan 28, 7:30 am, John Resig <jere...@gmail.com> wrote:
> > Feature Detection is all about checking how a feature behaves, and if
> > it behaves in a known faulty way, then apply the known fix. Instead of
> > checking whether browsers "support" each of the standard way of doing
> > things, the detection should be checking for known failures that need
> > fixing. Knowing that a browser does not support a standard way of
> > doing something does _not_ logically tell you the correct way to fix
> > it. You need to test to see how the feature behaves to know which fix,
> > if any, is most appropriate.
>
> You're still assuming that there's more than one possible fix. If we
> need more than one fix then we would certainly test for the
> applicability of each and work our way down - but as it stands there
> is no point in progressing that far (we already use many more browser
> features which would immediate exclude, or break, old browsers - such
> as document fragments, advanced regular expressions, etc.)
>
> There are two ways a one-fix situation can be done:
>
> if (standards_supported)
> use_standards_method()
> else
> apply_ie_fix()
> // non-ie, non-compliant, browsers are broken
>
> if (standards_supported)
> use_standards_method()
> else if ( can_do_ie_fix() )
> apply_ie_fix()
> else
> // non-ie, non-compliant, browsers are broken
>
> It doesn't matter - one way or the other the broken browser is still
> going to be broken - the only difference is that IE is going to be
> slower.
>
> Feature detection is about providing fixes to bugs in a manner that
> will gracefully continue to work when those bugs are fixed in new
> browsers (or if duplicate bugs are introduced elsewhere, in an other
> new browser).
>
> Feature detection is all about new and unknown browsers - hoping that
> your code will continue to persist. You conflate it with supporting
> old browsers that are lacking features - which is a completely
> separate set of discussions.
>
> For example, right now different parts of jQuery may break in older
> browsers - but the library, as a whole, will continue to try and
> operate. It's not clear if that's desirable - if we can't guarantee
> that all of the library should work, should we just quietly fail
> instead? One idea that I've been thinking of is to make it so that the
> callback passed to $(document).ready(function(){}) will just not
> execute if we can't guarantee that all of jQuery will work.
>
> This does a couple things:
> 1) Users of old browsers will simply have no JavaScript run (which is
> fine, since users of jQuery should be doing graceful degradation
> anyway).
> 2) This limits the set of possible browsers that will ever even hit
> the "jQuery.support" code to those that we actually have solutions
> for.
>
> I'll need to collect an assortment of older browsers, first, to
> determine what can and should be checked for a failure state (probably
> check Firefox 1.5, IE 5.5, Opera 8, Safari 1, etc.). This will be good
> since if we can't make a check to properly exclude an older browser
> (since it would be missing some critical feature) then we should
> probably work to support it fully.
>
> But - again - this is not feature detection as it's typically defined
> and should not be confused with feature detection. You're worried
> about old browsers failing gracefully - and that's a completely
> different set of issues from what normal bug fix feature detection
> should be handling.
>
> --John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
