What you're saying essentially boils down : if test_standard: standard else if test_alternate: alternate else: something
And for the something, you say: "blow up or do nothing or return false or something". jQuery does: if test_standard: standard else: alternate It seems like you're claiming that falling back naively to alternate is bad because things could break, beyond visual artifacts. And yet, it's acceptable to "blow up" in your ultimate else clause? What's the difference between breaking when an alternate method fails in a browser versus "blowing up" in a catchall clause? -- dz On Wed, Jan 28, 2009 at 3:32 PM, Matt <m...@thekrusefamily.com> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
