On Jan 14, 12:37 pm, John Resig <jere...@gmail.com> wrote: > Why would we test for non-standard behavior first? This would mean > that a browser that implements both a standard and non-standard > behavior would see a non-standard preference - which seems quite > wrong.
Agreed. > As to the logic structure that we use: > if ( support_standards ) > use_standards_technique() > else > use_other_known_technique(); I think it might be better as: support check: use_fix = ( !support_standards && supports_fix ) then: if ( use_fix ) use_fix() else use_standards() This way, you're applying the fix only if you can't do it the normal way and you _know_ the fix works. ( If !A && B Then B ) Using the existing logic, you're applying the fix if you can't do it the normal way, but you've never checked that the fix works! ( If !A Then B ) You're testing one behavior, then inferring another behavior based on your knowledge of a subset browsers you support. There is no test in your code that tells you that "cssText" will fix a broken "style". Instead of explicitly taking action based on the user agent string, you're assuming that the browser must be X if it doesn't support Y, and you know how to fix browser X, so you do that. This is not the spirit of feature detection, and is only a minor improvement over browser sniffing. > The reason why we choose this structure is that there really isn't a > third option. Yet. > If any of our jQuery.support > tests had three possible solutions then we would certainly opt for > that instead (but, as it turns out, all the things that we test for > only fail in a single browser, yielding only one correct alternative > solution). New browsers can pop into existence that you may wish to support (Chrome?). If you think of it only as a binary condition, there is no room for a new browser that implements it differently. Or, say IE 8.1 has a bug with opacity and needs its own little tweak. Just having a support check for "opacity" won't tell you which fix is needed, and you'll be stuck. > You're confusing our solution with a different problem set - we > designed this to work well with all browsers that we support and their > future releases (for when bug fixes come down the line) - you're > talking about something that works for all current browsers and any > theoretical past releases. That is a fools game and one that is both > impractical and illogical to follow. IMO, it is _more_ future-proof and just better logic. If it's a binary decision right now, then it should be all the same from your point of view. But if it becomes a non-binary situation, the existing logic fails whereas the other method would not. In the end, it works as-is and I'm thankful for it. It's just a bit disappointing to see the effort go into moving toward feature detection, but have it implemented in a way that will still not satisfy the js experts, and leave jQuery open to further criticism in this area. IMO. 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 -~----------~----~----~----~------~----~------~--~---
