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>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>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
>> > 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/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
-~----------~----~----~----~------~----~------~--~---
