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,
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
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
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
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,
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
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
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
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
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
... 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
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
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
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:
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 +
15 matches
Mail list logo
