On Jan 28, 1:20 pm, John Resig <jere...@gmail.com> wrote:
> Broken is broken is broken. Broken + no fix = broken. Broken + wrong
> fix = broken.
Sometimes broken=doesn't look quite right, while sometimes broken=no
longer functions.
> Ok - so what you're proposing here is something very different from
> what you said initially. You're saying:
> if (standards_supported || !use_ie_fix() )
> use_standards_method()
> // non-ie, non-compliant, browsers are broken
> else
> apply_ie_fix()
No, I'm saying the same as what I said in the previous thread:
use_standards = standards_test();
if (!use_standards)
if (fix1_test())
use_fix1 = true
endif
endif
Then you have a real picture of what the browser supports. Then in the
code you can simply do
if (use_standards)
do_standard_way
else if (use_fix1)
do_fix1_way
else
blow up or do nothing or return false or something
> In your case "Feature detection done correctly" is just another term
> for "having every known and theoretical permutation of a possible bug
> or bug in an API". It would have to include checks for all old
> browsers in addition to checks for all upcoming browsers - and provide
> fallbacks for all of them.
Not all. Just as many as is reasonable.
> > That is not the only place that jQuery is used, though. For example,
> > <input onchange="$(this).doSomething()">
> Uhhh... yes, someone could do that - but not only do we not encourage
> it (no documentation, etc.) but we actively disapprove of it as well.
Really? I have frequently unrolled things out of $(document).ready()
and put them inline because of performance problems caused by trying
to do everything up-front. Especially on webapps where IE (6,
especially) is the default browser. In fact just today I finished up
some work where I was un-jQuery-ifying some code to increase
performance in IE. (on a side note, dang, Chrome is fast).
Attaching everything on $(document).ready() is a mostly bad practice,
IMO, and I actively discourage it, for the most part. For very simple
pages, it is a fine approach, but on pages with any sufficient
complexity it is not the best practice. IMO.
I've also called jQuery methods quite often from non-jQuery functions.
To plug functionality into existing application frameworks, for
example, where I only have a function that I get to define or to
enhance existing functionality.
There are many ways to interact with jQuery, and assuming that they
all originate from $(document).ready() is a bad assumption, IMO.
> In short: If you're designing your site using good graceful
> degradation techniques to begin with, you'll get the benefit that we
> provide.
I don't think most of the jQuery examples or plugins are practicing
truly good graceful degradation. Since there is no way to predict up-
front whether jQuery will fail on a given method internally, there is
no way to know if a UI change should be applied. Sure, you can trap an
error as it happens, but by then it's too late to unroll the UI
changes you've already made under the assumption that js is enabled
and jQuery is running.
To do truly good graceful degradation, you need to ask up-front,
before you change anything in the UI:
1. Is the browser capable of running scripts?
2. Are all the components I'm going to rely on available?
3. Will they all function correctly?
4. Will the end result be as I expect?
If so, then go ahead! Otherwise, fall back. Currently, jQuery doesn't
offer enough details to know #2, #3, or #4. You have to dive in and
assume everything will work.
I know you've seen this page, but it really is a good look into the
issues:
http://peter.michaux.ca/articles/cross-browser-widgets
> > 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?
> It's very possible that that's a situation that we just don't support.
> Considering that, in that case, an exception would be thrown when the
> Ajax request was created - if a user, or a plugin, especially cared
> they would watch for the exception to be thrown.
As noted above, it may be too late. Other parts of the page may have
been setup to rely on Ajax because script was running and jQuery was
available. We would need to know up-front that ajax was unavailable in
order to make proper degradation decisions.
> Ideally, though, we should provide some level of fallback - barring
> that, just not support that browser in that situation and gracefully
> degrade.
I've worked in cases exactly like the above. It would be unfortunate
to remove jQuery from webapps simply because ajax wouldn't work
correctly, when it may not be used at all anyway. If jQuery wouldn't
run because a single component wasn't supported, that would make it
less useful, IMO.
Using the pseudo-code above, you could do:
ajax_available = true
use_xhr = xhr_test()
if (!use_xhr)
if (activex_test())
use_activex = true
else
ajax_available = false
endif
endif
This way, my script could check ajax_available early to see if it's
going to succeed. I can then make choices based on that.
Another example of this approach is: http://www.cinsoft.net/mylib.html
It's a little more extreme in its attempts to be robust, but it is
interesting to say the least.
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
-~----------~----~----~----~------~----~------~--~---
