On Jan 28, 9:30 am, John Resig <jere...@gmail.com> wrote:
> 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 then you're just rolling over to the logic that I'm proposing
should be there to begin with. Why not start with it?
> if (standards_supported)
> use_standards_method()
> else
> apply_ie_fix()
> // non-ie, non-compliant, browsers are broken
The problem is if a browser comes along that does not support
standards, but will break even further if you try to apply the IE fix.
You may make things _worse_ by blindly applying the IE fix. Or
whatever browser it is that you have the fix for.
> It doesn't matter - one way or the other the broken browser is still
> going to be broken
It is preferable to have a browser be "broken" in the sense that a
standard method was tried and didn't work correctly, than to have a
bad fix applied and have unpredictable results.
> 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.
Ancient browsers aren't my concern. Unpredictable current and future
browsers are.
Properly handling older browsers is just a bonus when feature
detection is done correctly.
> 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?
This is a problem with the current design, IMO. If a person wants to
use jQuery to do "graceful degradation", there is no way to check up-
front to see if everything is going to work correctly. The code
doesn't run through a battery of tests on initial setup to make sure
nothing is going to fail catastrophically down the line.
So, if I am going to convert an UL into tabs, for example, and I want
to maintain the existing interface for browsers that jQuery will
break, then I have a problem. If I run the code, I may get an error
somewhere in the middle and leave the screen in an unusable state. If
it fails silently, then I still have no way of knowing up-front if I
should even call the method to setup my tabs. Again I may be stuck in
some strange state that is unusable.
What would be preferable, IMO, is to be able to check up-front whether
jQuery is going to run without any problems:
if (jQuery.supported) {
// Do all my fancy stuff
}
Another option is to not even define jQuery if it is not available, so
I would then do:
if (jQuery) {
// Do jQuery stuff
}
Then, of course, any plugins or components that try to use jQuery
would need to take into account that it may not exist.
> 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.
That is not the only place that jQuery is used, though. For example,
<input onchange="$(this).doSomething()">
> 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.
This can be tricky. What if a particular browser has an opacity bug
with no fix and doesn't pass the "support" test, but works with
everything else? If I never mess with opacity in my scripts, why
should every other function of jQuery become unavailable?
That means you could then add a lot of different levels of jQuery
"support", and the developer could choose what they require and make
sure that it is available. This might be logically best, but it could
also create a mess. There may be a place in the middle that is ideal.
> 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.
Again, past browsers is just a small part of the concern. Current and
future browsers in environments that may be unpredictable (portable
devices, embedded devices, kiosks, higher security, etc) is the bigger
concern.
Consider an IE6 user in an environment where the administrators have
disabled ActiveX and ajax is not available. What happens? Will jQuery
choke, or continue to function in the most optimal way? Is there any
way for me, the author of a jQuery plugin, to know that some features
will not work correctly and should not be called? And how can I plan
for graceful degradation if I don't know where things will randomly
fail?
Matt Kruse
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
