Hi Karl, et al
"I think you're operating under a mistaken notion... The $.browser
method still exists."
DOH! Now I feel like an idiot. I've been following some threads and
perceived an urgency to the issue of replacing $.browser that made me
believe it was 'gone' in 1.3 - not just 'depricated' (a term often
misused). I've had users complaining that one of my plugins is not
working with 1.3, and jumped to conclusions.
Sorry for wasting your time, and thanks to those show responded.
However, I still believe it a mistake to depricate a method that
serves a useful purpose and has no replacement.
@malsup: It is convenient you only have a single feature (opacity) to
determine. But when dealing with multiple issues, including box-
models, bgIframe and similar issues all at once, a $.support
replacement is impractical. It is simpler to write custom
compatilitily methods and SKIP both $.browser and $.support - problem
solved.
@Matt: This may be functional...
useIframe:/*...@cc_on @*//*...@if (@_win32) true, @else @*/false,/*...@end @*/
But using a conditional comment 'hack' is just browser/platform
sniffing by another name. You could have written:
var isWin32 = false;
/*...@cc_on isWin32=true; @*/
var useIframe = isWin32;
So how is this 'better' than:
var useIframe = $.browser.msie && $.browser.version < 7;
Even the skilled developers in this forum cannot agreement how best to
'replace' $.browser functionality. Yet it will be depricated anyway.
Oh well. I've written browser/feature detectors since NN2, so can do
so again.
FYI, here is just one example of where I use 'browser detection' to
optimize functionality...
// IE CAN read dims of 'hidden' elements - FF CANNOT
if (!$.browser.msie) {
if ($.curCSS($E[0], "display", true) == "none") {
hidden = true; // set flag
// save current visibility
visibility = $.curCSS($E[0], "visibility", true);
// show element 'invisibly' so we can measure it
$E.css({ display: "block", visibility: "hidden" });
}
}
var val = parseInt($.curCSS($E[0], prop, true), 10) || 0;
As with bgIframe, there is no 'feature' to check, so $.support is
useless. I also don't care if some minor browser has the same
capability as IE - I just want to optimize for *the most common
browser in the world*. The rest can use the same flow as FireFox. When
I find a jQuery method that handles this for me, I'll dump this code
(its ugly anyway). But until then, I prefer to have 'choice' in how I
do things. But that's just me. ;)
Thanks again to the jQuery team. Fantastic work.
On Jan 25, 4:36 pm, Karl Swedberg <k...@englishrules.com> wrote:
> 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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
