Hi Kevin, While I appreciate your concerns, I think you're operating under a mistaken notion of what "deprecation" means. The $.browser method still exists. The whole idea of deprecation is to allow a transition period:
cf. http://en.wikipedia.org/wiki/Deprecation > Although deprecated features remain in the current version, their > use may raise warning messages recommending alternate practices, and > deprecation may indicate that the feature will be removed in the > future. Features are deprecated—rather than being removed—in order > to provide backward compatibility and give programmers using the > feature time to bring their code into compliance with the new > standard. --Karl ____________ Karl Swedberg www.englishrules.com www.learningjquery.com On Jan 25, 2009, at 6:57 PM, Kevin Dalman wrote: > > Feature detection is definately the way to go *when applicable*, so > $.support is a great addition to jQuery. > > However, I question the decision to depricate $.browser so abruptly. > This *forces* jQuery developers to create 'hacks' when feature > detection is not the best solution. The discussion here about IE6 and > bgIframe is a perfect example. We have top-notch Javascript developers > who agree on what feature detection *hack* to use to solve this > 'problem' that didn't exist before! How is this simplifying cross- > browser coding? > > In my opinion, jQuery should provide the toolkit, but leave the > *judgement* of when to use browser VS feature detection up to users. > It sometimes is cleaner and more efficient to check for the browser/ > version, rather of checking for *10 different features*, when I KNOW > all are unique to a specific browser/version. So using browser > detection, I can often branch alternate code more efficiently. This > should be *my choice*, and I wish jQuery would make BOTH options > easier, rather than limit my options. > > I realize it is late in the game to complain about depricating > $.browser. However, now that I'm testing v1.3, I see how many plugins > - including my own - are now 'broken'. I am now forced to choose > whether my plugins will support jQuery 1.2.6 OR 1.3 - I can't be > compatible with both. Why am I in this position? > > I understand that things change, but the deprication of $.browser > should have been clearly signalled to developers *at least one full > version in advance*. And this should only have been done AFTER adding > $.support, so that developers had an alternate utility. You have > unintentionally made life difficult for jQuery developers by not > proving a transition period where BOTH methods existed in jQuery. In > other words, $.browser should have been 'scheduled for deprication' in > v1.4 - not v1.3. > > Previous deprications were easy to fix - like $Elem.id() to $Elem.attr > ("id"). But feature detection is not an exact replacement for browser > detection when *multiple* browser-specific features are involved. > Replacing browser detection with feature detection can require > signficant changes to logic/flow, which in turn requires a lot of > testing. > > To smooth the transition to 1.3, I HIGHLY RECOMMEND A COMPATIBILITY > PACK. It doesn't need to include every depricated feature, but should > include the $.browser utility. This will allow plugin developers to > tell users who upgrade to v1.3 to include the v1.2 compatibility pack > to maintain the function of their plugins. This will provide time for > them to create a new version of the plugin compatible with v1.3 (which > will NOT be backwards compatible to 1.2.6 if they use $.support). > > Even though "I" believe $.browser should not have been depricated at > all, there is a more general principle here that I hope will be > considered for future updates to jQuery... > > When a method is being *replaced* by a new method, BOTH methods should > exist in jQuery for a suitable transition period. This allows > developers to modify their code *in advance* of the version where the > old method is depricated. You don't really have to support the old > code, because if a developer is 'working on the code', they can easily > switch to the new method instead. > > If you won't be creating an 'official' compatibility pack, then at a > minimum I suggest you create a backwards compatible $.browser plug-in, > and reference this on the main site. It could help speed the > transition to v1.3 for those using plugins and custom code that > reference $.browser. This way they can work with BOTH $.browser and > $.support SIMULTANEOUSLY, making it much easier to transition their > code step-by-step, as opposed to all-at-once. > > Thanks for indulging my long-winded rant. ;) It is intended as > *constructive* criticism - I hope it came across that way. > > / Kevin Dalman > > On Jan 23, 10:18 am, John Resig <jere...@gmail.com> wrote: >> >> On another note: You mentioned that this would be a good way to >> detect >> for IE 6. That is counter to everything that feature detection is >> designed for. Feature detection is supposed to be used on a >> case-by-case basis. If you need max-height then you use the >> $.support.maxHeight property to use it or provide a workaround. Using >> it to simply detect if IE 6 is being used is a huge assumption and is >> likely to cause things to break. >> >> --John >> >> On Thu, Jan 22, 2009 at 2:14 PM, Eric Martin <emarti...@gmail.com> >> wrote: >> >>> In order to transition away from $.browser to $.support, people are >>> going to want/need something to help identify IE6. >> >>> After a bit of research, I found one property that seems to work: >>> elem.style.maxHeight. IE6 returns undefined. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
