Hi all I'm not a js guru and could guess a disadvantage to use
something different but any way I could learn of the critic in this
thread...
On Wed, Jan 28, 2009 at 2:42 PM, David Zhou <da...@nodnod.net> wrote:
>
> What you're saying essentially boils down :
>
> if test_standard:
> standard
> else if test_alternate:
> alternate
> else:
> something
this is a good point but not enough, I prefer the suggest of John
if (standards_supported || !use_ie_fix() )
use_standards_method()
// non-ie, non-compliant, browsers are broken
else
apply_ie_fix()
but I really could imagine a structure
feature.detect='undetected';
switch(feature.detect){
case 'undetected': feature.detect=feature.supporType();
//don't break;
case 'standard':
standard()
break;
case 'fix1':
fix1()
break;
case 'fix2':
fix2()
break;
case 'unsupported': //exception
// Please don't do anything
break;
default:
// Really don't know how to do that fix
}
The great disadvantage I can see is the iterative check of feature.detect...
I listening what is the disadvantage of this, thanks for your patience.
Note: I use strings to simplify the reading I think should be numbers...
>
> 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
>>
>> >
>>
>
> >
>
--
Perhaps the depth of love can be calibrated by the number of different
selves that are actively involved in a given relationship.
Carl Sagan (Contact)
Jaime Ochoa Malagón
Arquitecto de Soluciones
Cel: +52 (55) 1021 0774
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
