And similarly... for IE (only), I often do "unload" cleanup functions (to remove DOM object references, closures, etc)... but for all other browsers, that's unncessary waste. Without a way to definitively, directly test for IE, how will my code know if it needs to do these cleanups or not... a "supportsProperMemoryManagement()"?
On Dec 22, 10:44 pm, 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- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
