Re: [jquery-dev] Re: status of $.browser
Jeremy, the docs are on a wiki. If you create an account on the wiki, I believe you'll automatically get write access after 24 hours. Would you like to take a cut at updating the $.browser docs the way you and Dave are talking about? Don't worry if it's not perfect or you don't cover every point, but what you just mentioned would be a pretty good addition right there. -Mike On Thu, Oct 29, 2009 at 11:09 AM, jez jez9...@gmail.com wrote: In the next incarnation of jQuery docs, could we please change the $.browser docs to reflect something similar to what Dave has said here? -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@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.
[jquery-dev] Re: status of $.browser
jQuery is not trying to stop you from detecting browsers, rendering engines, and/or features any way you'd like in your own code. It's just telling you to avoid the use of $.browser. jQuery core no longer uses $.browser internally because it was not reliable and it's impossible to test. The suggestion was that the jQuery documentation be reworded so that $.browser not be called 'Deprecated', but that its usage perhaps be discouraged. Take a look at http://dev.jquery.com/ticket/2661 . What better way to discourage its use than to have it return bad information? ;-) If $.browser remains in jQuery, people expect it to be correct for their definition of correct. Perhaps another round of patches in 1.4 can make it work well enough that there won't be tons of additional bugs reported against it, but I kind of doubt it. If it can't be fixed then I think it *should* be removed. You could argue that $.browser should use feature detection to guess browsers instead of userAgent, but that just opens a different can of worms. Consider http://dev.jquery.com/ticket/5391 . If Chrome and Safari essentially use the same core engine, should they be treated as a single browser or as different browsers? To answer that, you need to know if $.browser users are trying to detect the browser brand name, the browser rendering engine, or infer particular browser capabilities based on their own experimental observations. These dilemmas go away if you use feature detection or conditional comments instead of $.browser, because *you* know what you were really trying to get at. Or, craft your own detection based on the presence a feature you think is a good proxy for the feature you can't detect directly. For instance I'm developing a webpage and I happen to know that IE7 doesn't support the 'before' or 'after' pseudo selectors... It seems like it could be feature-detected with a small load-time test case with an element and some CSS to determine whether those pseudo selectors work. Or, just use conditional comments in your code if it's really IE-specific. -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@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.
[jquery-dev] Re: status of $.browser
OK Dave, I take this points and didn't realize that browser detection was quite so unreliable. I also didn't realize that you could test for whether a browser supports something as minor as a particular pseudo-selector. So I'm gonna change my request to this: In the next incarnation of jQuery docs, could we please change the $.browser docs to reflect something similar to what Dave has said here? Say that the browser detection is actually unreliable as browsers can and do lie about their model and version, and plugins change browser version strings too, and also emphasize that you can test for most things (eg. support for even individual CSS pseudo- selectors) so you shouldn't need it. Also point to various docs on how to test for various things that you may wish to test for, because I had to say I had no idea you could test for that. :-) Finally, I would suggest that even if $.browser is removed someday, these docs I'm suggesting stick around forever, just to tell people how they can achieve what they want instead without using (unreliable) browser version detection. Sooo... Could we at least change the docs in this way please? :-) Best regards, Jeremy Morton (Jez) On Oct 29, 5:14 pm, Dave Methvin dave.meth...@gmail.com wrote: jQuery is not trying to stop you from detecting browsers, rendering engines, and/or features any way you'd like in your own code. It's just telling you to avoid the use of $.browser. jQuery core no longer uses $.browser internally because it was not reliable and it's impossible to test. The suggestion was that the jQuery documentation be reworded so that $.browser not be called 'Deprecated', but that its usage perhaps be discouraged. Take a look athttp://dev.jquery.com/ticket/2661. What better way to discourage its use than to have it return bad information? ;-) If $.browser remains in jQuery, people expect it to be correct for their definition of correct. Perhaps another round of patches in 1.4 can make it work well enough that there won't be tons of additional bugs reported against it, but I kind of doubt it. If it can't be fixed then I think it *should* be removed. You could argue that $.browser should use feature detection to guess browsers instead of userAgent, but that just opens a different can of worms. Considerhttp://dev.jquery.com/ticket/5391. If Chrome and Safari essentially use the same core engine, should they be treated as a single browser or as different browsers? To answer that, you need to know if $.browser users are trying to detect the browser brand name, the browser rendering engine, or infer particular browser capabilities based on their own experimental observations. These dilemmas go away if you use feature detection or conditional comments instead of $.browser, because *you* know what you were really trying to get at. Or, craft your own detection based on the presence a feature you think is a good proxy for the feature you can't detect directly. For instance I'm developing a webpage and I happen to know that IE7 doesn't support the 'before' or 'after' pseudo selectors... It seems like it could be feature-detected with a small load-time test case with an element and some CSS to determine whether those pseudo selectors work. Or, just use conditional comments in your code if it's really IE-specific. -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@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.
[jquery-dev] Re: status of $.browser
i strongly support this. to my mind the notion that you can exclusively apply feature detection to the extremely complex browsers is optimistic. there just too many features and special cases to handle. On 28 Oct, 12:09, jez jez9...@gmail.com wrote: Sorry to reignite this debate in a new thread rather than replying to the old one, but for some reason Google Groups wouildn't let me reply to the old one. The suggestion was that the jQuery documentation be reworded so that $.browser not be called 'Deprecated', but that its usage perhaps be discouraged. I'd strongly support this rewording, John et al... could we please see it in the next version of the jQuery docs? I'm not sure I'd even go as far as 'strongly discouraging' the use of this property; sometimes it's a lot quicker and more convenient to use it than feature detection, and/or the feature detection just isn't there. For instance I'm developing a webpage and I happen to know that IE7 doesn't support the 'before' or 'after' pseudo selectors... I just want to detect whether this is IE7 and behave accordingly, as I can leave the other browsers alone and not need to emulate this css in Javascript. So for this reason I'd really like to see things reworded as something like 'please try to use $.support, but this can be used if necessary;. Also I'd like to see that word Deprecated dropped; it has a particular meaning in programming, which generally implies that it has been 100% obsoleted by something else and may well be dropped in a future release. I don't think this applies or should apply to $.browser, so it should not be called Deprecated. Best regards, Jeremy Morton (Jez) On Jul 6, 4:02 pm, John Resig jere...@gmail.com wrote: Re-wording the documentation from 'deprecated' to 'strongly discourage the use of' (or something similar) might be ok. I'm not sure what else we can do on our end - we already link to a number of guides that provide good information on the subject matter. As to the linked Stack Overflow discussion - perhaps injecting a rule into the stylesheet and then detecting to see if the rule sticks might work (not sure, just guessing off-hand). --John On Mon, Jul 6, 2009 at 11:53 AM, Ralph Whitbeckralph.whitb...@gmail.com wrote: As of 1.3 $.browseris listed as deprecated in support of jQuery.support. The thinking is that developers should be basing their checks on functionality instead of user agent strings. I think this is throwing a lot of novice jQuery users as they see the word deprecated and think that they shouldn't use it as the method is going away. From my understanding that method isn't going away. (http://osdir.com/ml/misc/2009-01/msg1.htmlAccording to John R, $.browserand version will remain in the core indefinitely, despite being deprecated...) For some cases it's really difficult to determine what piece of functionality to use to get the desired result. For instance, today, I noticed a coworker used $.browser.safari to build code specific to a Safari issue we were having. Knowing that $.browserwas listed as deprecated I went to find the correct way to segment out safari using $.support() unfortunately based on the docs I found this to be impossible to easily determine which is the best approach to use and I am still not sure it's possible. I did some research to see if there was an easy way to segment Safari from the rest using $.support() and found this thread on Stack Overflow that seems to support developer confusion on the issue. http://stackoverflow.com/questions/584285/detecting-ie6-using-jquery-... Developers want to do the right thing and listing the method as deprecated flags the developer to avoid that method at all costs. I think it would be better to list the method as not a best practice instead of deprecated and explain why functionality checks are better then user agent sniffing. Also it would be good to flush out some scenarios for developers to use which functionality test for certain browsers and certain scenarios. Thoughts? Am I off base on this? Ralph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [jquery-dev] Re: status of $.browser
ditto. On Wed, Oct 28, 2009 at 8:00 AM, weepy jonah...@gmail.com wrote: i strongly support this. to my mind the notion that you can exclusively apply feature detection to the extremely complex browsers is optimistic. there just too many features and special cases to handle. On 28 Oct, 12:09, jez jez9...@gmail.com wrote: Sorry to reignite this debate in a new thread rather than replying to the old one, but for some reason Google Groups wouildn't let me reply to the old one. The suggestion was that the jQuery documentation be reworded so that $.browser not be called 'Deprecated', but that its usage perhaps be discouraged. I'd strongly support this rewording, John et al... could we please see it in the next version of the jQuery docs? I'm not sure I'd even go as far as 'strongly discouraging' the use of this property; sometimes it's a lot quicker and more convenient to use it than feature detection, and/or the feature detection just isn't there. For instance I'm developing a webpage and I happen to know that IE7 doesn't support the 'before' or 'after' pseudo selectors... I just want to detect whether this is IE7 and behave accordingly, as I can leave the other browsers alone and not need to emulate this css in Javascript. So for this reason I'd really like to see things reworded as something like 'please try to use $.support, but this can be used if necessary;. Also I'd like to see that word Deprecated dropped; it has a particular meaning in programming, which generally implies that it has been 100% obsoleted by something else and may well be dropped in a future release. I don't think this applies or should apply to $.browser, so it should not be called Deprecated. Best regards, Jeremy Morton (Jez) On Jul 6, 4:02 pm, John Resig jere...@gmail.com wrote: Re-wording the documentation from 'deprecated' to 'strongly discourage the use of' (or something similar) might be ok. I'm not sure what else we can do on our end - we already link to a number of guides that provide good information on the subject matter. As to the linked Stack Overflow discussion - perhaps injecting a rule into the stylesheet and then detecting to see if the rule sticks might work (not sure, just guessing off-hand). --John On Mon, Jul 6, 2009 at 11:53 AM, Ralph Whitbeckralph.whitb...@gmail.com wrote: As of 1.3 $.browseris listed as deprecated in support of jQuery.support. The thinking is that developers should be basing their checks on functionality instead of user agent strings. I think this is throwing a lot of novice jQuery users as they see the word deprecated and think that they shouldn't use it as the method is going away. From my understanding that method isn't going away. (http://osdir.com/ml/misc/2009-01/msg1.htmlAccording to John R, $.browserand version will remain in the core indefinitely, despite being deprecated...) For some cases it's really difficult to determine what piece of functionality to use to get the desired result. For instance, today, I noticed a coworker used $.browser.safari to build code specific to a Safari issue we were having. Knowing that $.browserwas listed as deprecated I went to find the correct way to segment out safari using $.support() unfortunately based on the docs I found this to be impossible to easily determine which is the best approach to use and I am still not sure it's possible. I did some research to see if there was an easy way to segment Safari from the rest using $.support() and found this thread on Stack Overflow that seems to support developer confusion on the issue. http://stackoverflow.com/questions/584285/detecting-ie6-using-jquery-... Developers want to do the right thing and listing the method as deprecated flags the developer to avoid that method at all costs. I think it would be better to list the method as not a best practice instead of deprecated and explain why functionality checks are better then user agent sniffing. Also it would be good to flush out some scenarios for developers to use which functionality test for certain browsers and certain scenarios. Thoughts? Am I off base on this? Ralph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to
Re: [jquery-dev] Re: status of $.browser
I support this as well. On 2009-10-28, at 3:15 PM, Nathan Bubna wrote: ditto. On Wed, Oct 28, 2009 at 8:00 AM, weepy jonah...@gmail.com wrote: i strongly support this. to my mind the notion that you can exclusively apply feature detection to the extremely complex browsers is optimistic. there just too many features and special cases to handle. On 28 Oct, 12:09, jez jez9...@gmail.com wrote: Sorry to reignite this debate in a new thread rather than replying to the old one, but for some reason Google Groups wouildn't let me reply to the old one. The suggestion was that the jQuery documentation be reworded so that $.browser not be called 'Deprecated', but that its usage perhaps be discouraged. I'd strongly support this rewording, John et al... could we please see it in the next version of the jQuery docs? I'm not sure I'd even go as far as 'strongly discouraging' the use of this property; sometimes it's a lot quicker and more convenient to use it than feature detection, and/or the feature detection just isn't there. For instance I'm developing a webpage and I happen to know that IE7 doesn't support the 'before' or 'after' pseudo selectors... I just want to detect whether this is IE7 and behave accordingly, as I can leave the other browsers alone and not need to emulate this css in Javascript. So for this reason I'd really like to see things reworded as something like 'please try to use $.support, but this can be used if necessary;. Also I'd like to see that word Deprecated dropped; it has a particular meaning in programming, which generally implies that it has been 100% obsoleted by something else and may well be dropped in a future release. I don't think this applies or should apply to $.browser, so it should not be called Deprecated. Best regards, Jeremy Morton (Jez) On Jul 6, 4:02 pm, John Resig jere...@gmail.com wrote: Re-wording the documentation from 'deprecated' to 'strongly discourage the use of' (or something similar) might be ok. I'm not sure what else we can do on our end - we already link to a number of guides that provide good information on the subject matter. As to the linked Stack Overflow discussion - perhaps injecting a rule into the stylesheet and then detecting to see if the rule sticks might work (not sure, just guessing off-hand). --John On Mon, Jul 6, 2009 at 11:53 AM, Ralph Whitbeckralph.whitb...@gmail.com wrote: As of 1.3 $.browseris listed as deprecated in support of jQuery.support. The thinking is that developers should be basing their checks on functionality instead of user agent strings. I think this is throwing a lot of novice jQuery users as they see the word deprecated and think that they shouldn't use it as the method is going away. From my understanding that method isn't going away. (http://osdir.com/ml/misc/2009-01/msg1.htmlAccording to John R, $.browserand version will remain in the core indefinitely, despite being deprecated...) For some cases it's really difficult to determine what piece of functionality to use to get the desired result. For instance, today, I noticed a coworker used $.browser.safari to build code specific to a Safari issue we were having. Knowing that $.browserwas listed as deprecated I went to find the correct way to segment out safari using $.support() unfortunately based on the docs I found this to be impossible to easily determine which is the best approach to use and I am still not sure it's possible. I did some research to see if there was an easy way to segment Safari from the rest using $.support() and found this thread on Stack Overflow that seems to support developer confusion on the issue. http://stackoverflow.com/questions/584285/detecting-ie6-using-jquery- ... Developers want to do the right thing and listing the method as deprecated flags the developer to avoid that method at all costs. I think it would be better to list the method as not a best practice instead of deprecated and explain why functionality checks are better then user agent sniffing. Also it would be good to flush out some scenarios for developers to use which functionality test for certain browsers and certain scenarios. Thoughts? Am I off base on this? Ralph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- -- 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] Re: Status of $.browser
One simple example might be in IE6 where you need to add a transparent iframe to stop select elements from bleeding through html elements that are on top of them. I'm not aware of any way to detect this need by testing functionality. (Someone else on this thread has quite rightly suggested the use of conditional comments as a way to tackle situations like this. Yep, they could be used to separate special js functionality.) George --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: Status of $.browser
Conditional statements are great for IE problems but it doesn't help when you need to isolate a problem with Mozilla or Safari browsers. All I am suggesting is that the word Deprecated be swapped with something not so strong in meaning to something that conveys it's not the best practice to use browser sniffing and that functionality testing should be used when applicable instead. Ralph On Wed, Jul 8, 2009 at 3:13 PM, George george.jqu...@softwareunity.comwrote: One simple example might be in IE6 where you need to add a transparent iframe to stop select elements from bleeding through html elements that are on top of them. I'm not aware of any way to detect this need by testing functionality. (Someone else on this thread has quite rightly suggested the use of conditional comments as a way to tackle situations like this. Yep, they could be used to separate special js functionality.) George --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: Status of $.browser
I think a generic $.browser.IE could always be useful ... sometimes we have
to deal with pixel perfection and I cannot imagine how many features
detections we should do to understand if a table should be 360px rather than
358px cause of duplicated css padding rule ... what I mean is that feature
detection are not always possible.
Most simple example? redefine setTimeout making it accept extra arguments as
well. If you test this via timeout every sync script in the meanwhile could
have get it wrong.
I hope you got my point ( and I do not thing we will all agree into a
delayed timed execution environment, do we? )
Regards
On Mon, Jul 6, 2009 at 5:47 PM, Ralph Whitbeck ralph.whitb...@gmail.comwrote:
Rick, from what I understand the reason we singled out Safari was we were
having an issue with fadeIn, here is the code I found in subversion:
if ($.browser.safari) {
// Safari fadeIn fix- just display it straight.
$(#components a.SingleImage + currentPage +
_plcSideContent1).css(display, inline);
}
else {
$(#components a.SingleImage + currentPage +
_plcSideContent1).fadeIn(fast);
}
I'll have to get more info if you need it from the developer that posted it
when he get's back from lunch.
Thanks,
Ralph
On Mon, Jul 6, 2009 at 12:42 PM, Rick Waldron waldron.r...@gmail.comwrote:
Ralph,
I'm just sort of curious... could you post up the $.browser.safari
scenario (explanation of goal as well as code used to reach said goal)?
A little curious to see what was trying to be achieved.
Rick
On Mon, Jul 6, 2009 at 12:16 PM, Ralph Whitbeck ralph.whitb...@gmail.com
wrote:
John,
From my experience, I clicked on those guides in the docs and I felt
overwhelmed with information when I was looking for a quick solution to my
problem. Just my two cents.
As per the SO discussion I just wanted to highlight the comments mostly
where developers say it's deprecated don't use it and the other developers
asking then what to do instead.
Thanks,
Ralph
On Mon, Jul 6, 2009 at 12:02 PM, John Resig jere...@gmail.com wrote:
Re-wording the documentation from 'deprecated' to 'strongly discourage
the use of' (or something similar) might be ok. I'm not sure what else
we can do on our end - we already link to a number of guides that
provide good information on the subject matter.
As to the linked Stack Overflow discussion - perhaps injecting a rule
into the stylesheet and then detecting to see if the rule sticks might
work (not sure, just guessing off-hand).
--John
On Mon, Jul 6, 2009 at 11:53 AM, Ralph Whitbeck
ralph.whitb...@gmail.com wrote:
As of 1.3 $.browser is listed as deprecated in support of
jQuery.support.
The thinking is that developers should be basing their checks on
functionality instead of user agent strings.
I think this is throwing a lot of novice jQuery users as they see the
word
deprecated and think that they shouldn't use it as the method is going
away. From my understanding that method isn't going away.
(http://osdir.com/ml/misc/2009-01/msg1.html According to John R,
$.browser and version will remain in the core indefinitely, despite
being
deprecated...) For some cases it's really difficult to determine
what
piece of functionality to use to get the desired result. For
instance,
today, I noticed a coworker used $.browser.safari to build code
specific to
a Safari issue we were having. Knowing that $.browser was listed as
deprecated I went to find the correct way to segment out safari using
$.support() unfortunately based on the docs I found this to be
impossible to
easily determine which is the best approach to use and I am still not
sure
it's possible.
I did some research to see if there was an easy way to segment Safari
from
the rest using $.support() and found this thread on Stack Overflow
that
seems to support developer confusion on the issue.
http://stackoverflow.com/questions/584285/detecting-ie6-using-jquery-support
Developers want to do the right thing and listing the method as
deprecated
flags the developer to avoid that method at all costs. I think it
would be
better to list the method as not a best practice instead of
deprecated and
explain why functionality checks are better then user agent sniffing.
Also it would be good to flush out some scenarios for developers to
use
which functionality test for certain browsers and certain scenarios.
Thoughts? Am I off base on this?
Ralph
--~--~-~--~~~---~--~~
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
[jquery-dev] Re: Status of $.browser
Conditional comments are a far better way to test for IE than
$.browser.msie is, and those alternate .css rules would be best in an
ie.css included via conditional comments.
As for setTimeout, it has no need for extra arguments. If you think you
need extra arguments to setTimeout, then you don't know how to use one
of JavaScript's core features, closures.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Andrea Giammarchi wrote:
I think a generic $.browser.IE could always be useful ... sometimes we
have to deal with pixel perfection and I cannot imagine how many
features detections we should do to understand if a table should be
360px rather than 358px cause of duplicated css padding rule ... what
I mean is that feature detection are not always possible.
Most simple example? redefine setTimeout making it accept extra
arguments as well. If you test this via timeout every sync script in
the meanwhile could have get it wrong.
I hope you got my point ( and I do not thing we will all agree into a
delayed timed execution environment, do we? )
Regards
On Mon, Jul 6, 2009 at 5:47 PM, Ralph Whitbeck
ralph.whitb...@gmail.com mailto:ralph.whitb...@gmail.com wrote:
Rick, from what I understand the reason we singled out Safari was
we were having an issue with fadeIn, here is the code I found in
subversion:
if ($.browser.safari) {
// Safari fadeIn fix- just display it straight.
$(#components a.SingleImage + currentPage +
_plcSideContent1).css(display, inline);
}
else {
$(#components a.SingleImage + currentPage +
_plcSideContent1).fadeIn(fast);
}
I'll have to get more info if you need it from the developer that
posted it when he get's back from lunch.
Thanks,
Ralph
On Mon, Jul 6, 2009 at 12:42 PM, Rick Waldron
waldron.r...@gmail.com mailto:waldron.r...@gmail.com wrote:
Ralph,
I'm just sort of curious... could you post up the
$.browser.safari scenario (explanation of goal as well as code
used to reach said goal)?
A little curious to see what was trying to be achieved.
Rick
On Mon, Jul 6, 2009 at 12:16 PM, Ralph Whitbeck
ralph.whitb...@gmail.com mailto:ralph.whitb...@gmail.com
wrote:
John,
From my experience, I clicked on those guides in the docs
and I felt overwhelmed with information when I was looking
for a quick solution to my problem. Just my two cents.
As per the SO discussion I just wanted to highlight the
comments mostly where developers say it's deprecated don't
use it and the other developers asking then what to do
instead.
Thanks,
Ralph
On Mon, Jul 6, 2009 at 12:02 PM, John Resig
jere...@gmail.com mailto:jere...@gmail.com wrote:
Re-wording the documentation from 'deprecated' to
'strongly discourage
the use of' (or something similar) might be ok. I'm
not sure what else
we can do on our end - we already link to a number of
guides that
provide good information on the subject matter.
As to the linked Stack Overflow discussion - perhaps
injecting a rule
into the stylesheet and then detecting to see if the
rule sticks might
work (not sure, just guessing off-hand).
--John
On Mon, Jul 6, 2009 at 11:53 AM, Ralph
Whitbeckralph.whitb...@gmail.com
mailto:ralph.whitb...@gmail.com wrote:
As of 1.3 $.browser is listed as deprecated in
support of jQuery.support.
The thinking is that developers should be basing
their checks on
functionality instead of user agent strings.
I think this is throwing a lot of novice jQuery
users as they see the word
deprecated and think that they shouldn't use it as
the method is going
away. From my understanding that method isn't going
away.
(http://osdir.com/ml/misc/2009-01/msg1.html
According to John R,
$.browser and version will remain in the core
indefinitely, despite being
deprecated...) For some cases it's really
difficult to determine what
piece of functionality to use to get the desired
result. For instance,
today, I noticed a coworker used $.browser.safari to
build code specific to
[jquery-dev] Re: Status of $.browser
... and you do not know how to reuse functions ... Daniel, dunno why this
answer, setTimeout works like that before you started to write javascript,
it has always been like that, only IE and some Opera did not get it.
function myReusableFunction(arg1, arg2){
// do your stuff, reuse the function if necessary, avoid useless
closures and redundant code
};
setTimeout(myReusableFunction, 1000, a, {b:c});
Tell me a single reason I should write every time a new function, slower,
with a new closure, slower, to call an already defined function.
setTimeout(function(){
myReusableFunction(a, {b:c})
}, 1000);
Now, rather than this, think about setInterval, and make your knowledge
about ECMAScript deeper.
Thanks
On Tue, Jul 7, 2009 at 5:41 PM, Daniel Friesen nadir.seen.f...@gmail.comwrote:
As for setTimeout, it has no need for extra arguments. If you think you
need extra arguments to setTimeout, then you don't know how to use one
of JavaScript's core features, closures.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[jquery-dev] Re: Status of $.browser
Re-wording the documentation from 'deprecated' to 'strongly discourage the use of' (or something similar) might be ok. I'm not sure what else we can do on our end - we already link to a number of guides that provide good information on the subject matter. As to the linked Stack Overflow discussion - perhaps injecting a rule into the stylesheet and then detecting to see if the rule sticks might work (not sure, just guessing off-hand). --John On Mon, Jul 6, 2009 at 11:53 AM, Ralph Whitbeckralph.whitb...@gmail.com wrote: As of 1.3 $.browser is listed as deprecated in support of jQuery.support. The thinking is that developers should be basing their checks on functionality instead of user agent strings. I think this is throwing a lot of novice jQuery users as they see the word deprecated and think that they shouldn't use it as the method is going away. From my understanding that method isn't going away. (http://osdir.com/ml/misc/2009-01/msg1.html According to John R, $.browser and version will remain in the core indefinitely, despite being deprecated...) For some cases it's really difficult to determine what piece of functionality to use to get the desired result. For instance, today, I noticed a coworker used $.browser.safari to build code specific to a Safari issue we were having. Knowing that $.browser was listed as deprecated I went to find the correct way to segment out safari using $.support() unfortunately based on the docs I found this to be impossible to easily determine which is the best approach to use and I am still not sure it's possible. I did some research to see if there was an easy way to segment Safari from the rest using $.support() and found this thread on Stack Overflow that seems to support developer confusion on the issue. http://stackoverflow.com/questions/584285/detecting-ie6-using-jquery-support Developers want to do the right thing and listing the method as deprecated flags the developer to avoid that method at all costs. I think it would be better to list the method as not a best practice instead of deprecated and explain why functionality checks are better then user agent sniffing. Also it would be good to flush out some scenarios for developers to use which functionality test for certain browsers and certain scenarios. Thoughts? Am I off base on this? Ralph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: Status of $.browser
John, From my experience, I clicked on those guides in the docs and I felt overwhelmed with information when I was looking for a quick solution to my problem. Just my two cents. As per the SO discussion I just wanted to highlight the comments mostly where developers say it's deprecated don't use it and the other developers asking then what to do instead. Thanks, Ralph On Mon, Jul 6, 2009 at 12:02 PM, John Resig jere...@gmail.com wrote: Re-wording the documentation from 'deprecated' to 'strongly discourage the use of' (or something similar) might be ok. I'm not sure what else we can do on our end - we already link to a number of guides that provide good information on the subject matter. As to the linked Stack Overflow discussion - perhaps injecting a rule into the stylesheet and then detecting to see if the rule sticks might work (not sure, just guessing off-hand). --John On Mon, Jul 6, 2009 at 11:53 AM, Ralph Whitbeckralph.whitb...@gmail.com wrote: As of 1.3 $.browser is listed as deprecated in support of jQuery.support. The thinking is that developers should be basing their checks on functionality instead of user agent strings. I think this is throwing a lot of novice jQuery users as they see the word deprecated and think that they shouldn't use it as the method is going away. From my understanding that method isn't going away. (http://osdir.com/ml/misc/2009-01/msg1.html According to John R, $.browser and version will remain in the core indefinitely, despite being deprecated...) For some cases it's really difficult to determine what piece of functionality to use to get the desired result. For instance, today, I noticed a coworker used $.browser.safari to build code specific to a Safari issue we were having. Knowing that $.browser was listed as deprecated I went to find the correct way to segment out safari using $.support() unfortunately based on the docs I found this to be impossible to easily determine which is the best approach to use and I am still not sure it's possible. I did some research to see if there was an easy way to segment Safari from the rest using $.support() and found this thread on Stack Overflow that seems to support developer confusion on the issue. http://stackoverflow.com/questions/584285/detecting-ie6-using-jquery-support Developers want to do the right thing and listing the method as deprecated flags the developer to avoid that method at all costs. I think it would be better to list the method as not a best practice instead of deprecated and explain why functionality checks are better then user agent sniffing. Also it would be good to flush out some scenarios for developers to use which functionality test for certain browsers and certain scenarios. Thoughts? Am I off base on this? Ralph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: Status of $.browser
Ralph, I'm just sort of curious... could you post up the $.browser.safari scenario (explanation of goal as well as code used to reach said goal)? A little curious to see what was trying to be achieved. Rick On Mon, Jul 6, 2009 at 12:16 PM, Ralph Whitbeck ralph.whitb...@gmail.comwrote: John, From my experience, I clicked on those guides in the docs and I felt overwhelmed with information when I was looking for a quick solution to my problem. Just my two cents. As per the SO discussion I just wanted to highlight the comments mostly where developers say it's deprecated don't use it and the other developers asking then what to do instead. Thanks, Ralph On Mon, Jul 6, 2009 at 12:02 PM, John Resig jere...@gmail.com wrote: Re-wording the documentation from 'deprecated' to 'strongly discourage the use of' (or something similar) might be ok. I'm not sure what else we can do on our end - we already link to a number of guides that provide good information on the subject matter. As to the linked Stack Overflow discussion - perhaps injecting a rule into the stylesheet and then detecting to see if the rule sticks might work (not sure, just guessing off-hand). --John On Mon, Jul 6, 2009 at 11:53 AM, Ralph Whitbeckralph.whitb...@gmail.com wrote: As of 1.3 $.browser is listed as deprecated in support of jQuery.support. The thinking is that developers should be basing their checks on functionality instead of user agent strings. I think this is throwing a lot of novice jQuery users as they see the word deprecated and think that they shouldn't use it as the method is going away. From my understanding that method isn't going away. (http://osdir.com/ml/misc/2009-01/msg1.html According to John R, $.browser and version will remain in the core indefinitely, despite being deprecated...) For some cases it's really difficult to determine what piece of functionality to use to get the desired result. For instance, today, I noticed a coworker used $.browser.safari to build code specific to a Safari issue we were having. Knowing that $.browser was listed as deprecated I went to find the correct way to segment out safari using $.support() unfortunately based on the docs I found this to be impossible to easily determine which is the best approach to use and I am still not sure it's possible. I did some research to see if there was an easy way to segment Safari from the rest using $.support() and found this thread on Stack Overflow that seems to support developer confusion on the issue. http://stackoverflow.com/questions/584285/detecting-ie6-using-jquery-support Developers want to do the right thing and listing the method as deprecated flags the developer to avoid that method at all costs. I think it would be better to list the method as not a best practice instead of deprecated and explain why functionality checks are better then user agent sniffing. Also it would be good to flush out some scenarios for developers to use which functionality test for certain browsers and certain scenarios. Thoughts? Am I off base on this? Ralph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: Status of $.browser
Rick, from what I understand the reason we singled out Safari was we were
having an issue with fadeIn, here is the code I found in subversion:
if ($.browser.safari) {
// Safari fadeIn fix- just display it straight.
$(#components a.SingleImage + currentPage +
_plcSideContent1).css(display, inline);
}
else {
$(#components a.SingleImage + currentPage +
_plcSideContent1).fadeIn(fast);
}
I'll have to get more info if you need it from the developer that posted it
when he get's back from lunch.
Thanks,
Ralph
On Mon, Jul 6, 2009 at 12:42 PM, Rick Waldron waldron.r...@gmail.comwrote:
Ralph,
I'm just sort of curious... could you post up the $.browser.safari scenario
(explanation of goal as well as code used to reach said goal)?
A little curious to see what was trying to be achieved.
Rick
On Mon, Jul 6, 2009 at 12:16 PM, Ralph Whitbeck
ralph.whitb...@gmail.comwrote:
John,
From my experience, I clicked on those guides in the docs and I felt
overwhelmed with information when I was looking for a quick solution to my
problem. Just my two cents.
As per the SO discussion I just wanted to highlight the comments mostly
where developers say it's deprecated don't use it and the other developers
asking then what to do instead.
Thanks,
Ralph
On Mon, Jul 6, 2009 at 12:02 PM, John Resig jere...@gmail.com wrote:
Re-wording the documentation from 'deprecated' to 'strongly discourage
the use of' (or something similar) might be ok. I'm not sure what else
we can do on our end - we already link to a number of guides that
provide good information on the subject matter.
As to the linked Stack Overflow discussion - perhaps injecting a rule
into the stylesheet and then detecting to see if the rule sticks might
work (not sure, just guessing off-hand).
--John
On Mon, Jul 6, 2009 at 11:53 AM, Ralph Whitbeckralph.whitb...@gmail.com
wrote:
As of 1.3 $.browser is listed as deprecated in support of
jQuery.support.
The thinking is that developers should be basing their checks on
functionality instead of user agent strings.
I think this is throwing a lot of novice jQuery users as they see the
word
deprecated and think that they shouldn't use it as the method is going
away. From my understanding that method isn't going away.
(http://osdir.com/ml/misc/2009-01/msg1.html According to John R,
$.browser and version will remain in the core indefinitely, despite
being
deprecated...) For some cases it's really difficult to determine what
piece of functionality to use to get the desired result. For instance,
today, I noticed a coworker used $.browser.safari to build code
specific to
a Safari issue we were having. Knowing that $.browser was listed as
deprecated I went to find the correct way to segment out safari using
$.support() unfortunately based on the docs I found this to be
impossible to
easily determine which is the best approach to use and I am still not
sure
it's possible.
I did some research to see if there was an easy way to segment Safari
from
the rest using $.support() and found this thread on Stack Overflow that
seems to support developer confusion on the issue.
http://stackoverflow.com/questions/584285/detecting-ie6-using-jquery-support
Developers want to do the right thing and listing the method as
deprecated
flags the developer to avoid that method at all costs. I think it
would be
better to list the method as not a best practice instead of
deprecated and
explain why functionality checks are better then user agent sniffing.
Also it would be good to flush out some scenarios for developers to use
which functionality test for certain browsers and certain scenarios.
Thoughts? Am I off base on this?
Ralph
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
