Yes, but you're still encouraged to go the same way and replace your usage of jQuery.browser with feature detection.
Jörn On Tue, Dec 23, 2008 at 7:28 PM, Ricardo Tomasi <[email protected]> wrote: > > I thought browser detection wasn't going to be used in jQuery's core > anymore, but jQuery.browser would remain for end-users, am I right? > > - ricardo > > On Dec 23, 2:44 am, Shade <[email protected]> wrote: >> Just a question/thought on the complete deprecation of >> jQuery.browser.... I know the new model is to go toward a >> "supportsXXXX" type declarative syntax for testing of support. And I >> agree with that approach... in theory. >> >> But what about frustrating browser differences that are just that -- >> browser differences, and not really "supports" of any thing, >> especially not javascript related specifically. >> >> For instance, I have some jQuery code that breaks up long text/URL's >> by inserting word-breaks to allow for more normal line breaking/ >> wrapping. Thanks to quirksmode.org, it is seen that for most >> browsers, the <wbr> tag is the one to use for such a feat. But for >> safari, the ­ is better (since <wbr> is only supported once on a >> "line" by safari). >> >> So, I have a line of jQuery code testing 'jQuery.browser.safari' to >> decide which "break character/entity" to use. So, my question is, how >> on earth would I do this with the new syntax and wean myself off the >> deprecated syntax? It's not even a javascript thing. It's just a >> browser/rendering support thing. But with no direct way to know what >> browser I'm in, how will I accomplish it? >> >> I guess somehow I'd need to create a "supportsWBR" or something like >> that? >> >> Paul Bakaus wrote: >> > Hey John, >> >> > first off, nice job with the live query / jQuery.support commits! I'm >> > almost /feeling/ the improvements, without even testing them :) >> >> > I'm curious about a couple lines in the commit, thought you might >> > explain them to us: >> >> > - ajax.js: It seems instead of a substitute, you simply removed the >> > safari check. What was the reason for this? >> >> > - core.js: removal of opera/display fix, color() method with safari >> > fix, the whole display none logic - does this mean we simply don't >> > support getting some style values for display:none elements? (which is >> > fine, just wanted to check) >> >> > Other than that, it looks all good, a lot of nice fixes / better logic >> > in there, especially in event.js. Thanks! >> >> > Cheers, >> > Paul > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
