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
-~----------~----~----~----~------~----~------~--~---
