I'll try not to beat a dead horse, since I've stated my views. But it does often take some repeated pushing to get js developers to change their thinking and see the benefits of true feature detection. I'm happy to continue this discussion and really get into the dirty details of finding the best solutions if anyone is interested. I think it's an interesting technical challenge.
On Jan 26, 7:35 pm, Kevin Dalman <kevin.dal...@gmail.com> wrote: > @Matt: Re: "Why not just check the value, and if it is 0 or undefined/ > null, apply the "visibility" fix?" > Because this is a generic method - some properties can be read when > hidden and some can't. Plus '0' is a valid dimension, so it might mean > there is no border or it might not! Then you only apply the fix for the properties that you know cause this "quirk". The reasoning is simple - Try not to make assumptions, and try to only fix what is broken. If you know that you need a dimension, and in some browsers this dimension is returned incorrectly, then if you are checking that dimension you need to apply the fix if the value is invalid. I don't think it's a good strategy to use a less-effective fix simply because it requires a few more if conditions. > I *could* create and test a bunch > of alternate work-arounds, but if it ain't broke, don't fix it! It just depends on what your version of "broke" means. jQuery and many plugins purposely limit the "supported browser" list because of the techniques being used. It becomes unmanageable to try to support many browsers if you are using browser sniffing and hacks and work-arounds. However, if you use proper feature-detection and apply fixes only in the cases where there are known problems, and if you fix problems in a way that applies only if the problem exists, then you become completely browser-agnostic. For example, IE8RC1 is out now. If a bug in IE7 somehow crept back into this version of IE8, and you were checking the browser version and applying a fix for only <=7, the bug wouldn't be fixed in the new browser. If you fixed the problem in a generic way, then _any_ browser - whether IE or not, and for all previous and future versions - would be fixed. Isn't this preferred? Chrome is a good example - it uses WebKit but has its own js engine, so it may have some bugs similar to Safari and it may have some of its own. If existing code is checking specifically for Safari to apply fixes, then these fixes wouldn't be applied to Chrome. Wouldn't it be better to detect the problems known to exist in Safari and fix them if they are detected? Then any browser using WebKit that may have the same problems would also be fixed. What about browsers on portable devices? They are a different beast in many respects, but well-written code should continue to function and apply fixes for known problems, regardless of the user agent. jQuery is growing in popularity and becoming the framework of choice for many developers and web sites. It should continue to use more robust and browser-agnostic coding practices to ensure that it works on as many browsers as possible, in as many environments as possible. Developers shouldn't be just looking for "what works" in the official supported browser list. They should be challenged to fix problems in a reliable, logical, robust way. That will only make the library better and more able to stand up to criticisms from the js gurus. > Just for the heck of it, here's another example from the same plugin. > I'm sure there are other ways to detect IE6 and IE7 quirks-mode, but I > doubt any are more consise and readable than this if-statement... I don't really understand the problem this is trying to fix, so I'm not sure of a better alternative. > A non-compatible browser that *claims* to be IE will break millions of > websites Only those written poorly. >, so frankly I don't care about such fringe examples. The > dozens of browsers I've tested that emulate/shell IE - including > FireFox with its "IE Tab" plugin - all work *perfectly* with browser > sniffing. Why? Because they are designed to do so That's because they _are_ IE and report themselves as such. If the IETab plugin reported itself as Firefox, you would have all kinds of problems with any code using browser sniffing. But proper feature- detecting would work no matter what the browser called itself. New browsers that share a rendering engine like WebKit but have a completely new and unrecognized user-agent header are more of a concern. Browser sniffing effectively locks them out from fixes that would make the browser behave correctly. Feature detection would allow those browsers to work correctly. Especially for web sites where traffic=money, why would someone want to purposely _reduce_ browser support by choosing a less-effective strategy from two available options? > "Nearly every issue can be addressed using proper feature detection > strategies rather than browser sniffing." > Except your own example that is, or mine. "Nearly" is not "all". Isn't > that the point? The iframe example is an exception. I think I addressed yours without browser sniffing. In cases where it is truly not possible to apply a fix without some browser detection, it may be justified. Those cases are extremely rare. And the better alternative would be to refactor the problem out to begin with. 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 -~----------~----~----~----~------~----~------~--~---
