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 > Whitbeck<ralph.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/msg00001.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 -~----------~----~----~----~------~----~------~--~---
