status of $.browser

[jez9999]

Sorry to reignite this debate in a new thread rather than replying to
the old one, but for some reason Google Groups wouildn't let me reply
to the old one.  The suggestion was that the jQuery documentation be
reworded so that $.browser not be called 'Deprecated', but that its
usage perhaps be discouraged.  I'd strongly support this rewording,
John et al... could we please see it in the next version of the jQuery
docs?

I'm not sure I'd even go as far as 'strongly discouraging' the use of
this property; sometimes it's a lot quicker and more convenient to use
it than feature detection, and/or the feature detection just isn't
there.  For instance I'm developing a webpage and I happen to know
that IE7 doesn't support the 'before' or 'after' pseudo selectors... I
just want to detect whether this is IE7 and behave accordingly, as I
can leave the other browsers alone and not need to emulate this css in
Javascript.  So for this reason I'd really like to see things reworded
as something like 'please try to use $.support, but this can be used
if necessary;.  Also I'd like to see that word Deprecated dropped; it
has a particular meaning in programming, which generally implies that
it has been 100% obsoleted by something else and may well be dropped
in a future release.  I don't think this applies or should apply to
$.browser, so it should not be called Deprecated.

Best regards,
Jeremy Morton (Jez)

On Jul 6, 4:02 pm, John Resig <jere...@...> 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...@...> wrote:
> > As of 1.3 $.browseris 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,
> > $.browserand 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 $.browserwas 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-...
>
> > 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@...
To unsubscribe from this group, send email to jquery-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[weepy]

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, jez9999 <jez9...@...> wrote:

> Sorry to reignite this debate in a new thread rather than replying to
> the old one, but for some reason Google Groups wouildn't let me reply
> to the old one.  The suggestion was that the jQuery documentation be
> reworded so that $.browser not be called 'Deprecated', but that its
> usage perhaps be discouraged.  I'd strongly support this rewording,
> John et al... could we please see it in the next version of the jQuery
> docs?
>
> I'm not sure I'd even go as far as 'strongly discouraging' the use of
> this property; sometimes it's a lot quicker and more convenient to use
> it than feature detection, and/or the feature detection just isn't
> there.  For instance I'm developing a webpage and I happen to know
> that IE7 doesn't support the 'before' or 'after' pseudo selectors... I
> just want to detect whether this is IE7 and behave accordingly, as I
> can leave the other browsers alone and not need to emulate this css in
> Javascript.  So for this reason I'd really like to see things reworded
> as something like 'please try to use $.support, but this can be used
> if necessary;.  Also I'd like to see that word Deprecated dropped; it
> has a particular meaning in programming, which generally implies that
> it has been 100% obsoleted by something else and may well be dropped
> in a future release.  I don't think this applies or should apply to
> $.browser, so it should not be called Deprecated.
>
> Best regards,
> Jeremy Morton (Jez)
>
> On Jul 6, 4:02 pm, John Resig <jere...@...> 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...@...> wrote:
> > > As of 1.3 $.browseris 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,
> > > $.browserand 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 $.browserwas 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-...
>
> > > 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@...
To unsubscribe from this group, send email to jquery-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Nathan Bubna]

ditto.

On Wed, Oct 28, 2009 at 8:00 AM, weepy <jonahfox@...> 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, 12:09, jez9999 <jez9...@...> wrote:
>> Sorry to reignite this debate in a new thread rather than replying to
>> the old one, but for some reason Google Groups wouildn't let me reply
>> to the old one.  The suggestion was that the jQuery documentation be
>> reworded so that $.browser not be called 'Deprecated', but that its
>> usage perhaps be discouraged.  I'd strongly support this rewording,
>> John et al... could we please see it in the next version of the jQuery
>> docs?
>>
>> I'm not sure I'd even go as far as 'strongly discouraging' the use of
>> this property; sometimes it's a lot quicker and more convenient to use
>> it than feature detection, and/or the feature detection just isn't
>> there.  For instance I'm developing a webpage and I happen to know
>> that IE7 doesn't support the 'before' or 'after' pseudo selectors... I
>> just want to detect whether this is IE7 and behave accordingly, as I
>> can leave the other browsers alone and not need to emulate this css in
>> Javascript.  So for this reason I'd really like to see things reworded
>> as something like 'please try to use $.support, but this can be used
>> if necessary;.  Also I'd like to see that word Deprecated dropped; it
>> has a particular meaning in programming, which generally implies that
>> it has been 100% obsoleted by something else and may well be dropped
>> in a future release.  I don't think this applies or should apply to
>> $.browser, so it should not be called Deprecated.
>>
>> Best regards,
>> Jeremy Morton (Jez)
>>
>> On Jul 6, 4:02 pm, John Resig <jere...@...> 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...@...> wrote:
>> > > As of 1.3 $.browseris 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,
>> > > $.browserand 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 $.browserwas 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-...
>>
>> > > 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@...
> To unsubscribe from this group, send email to jquery-dev+unsubscribe@...
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Samer Ziadeh]

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 <jonahfox@...> 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, 12:09, jez9999 <jez9...@...> wrote:
>>> Sorry to reignite this debate in a new thread rather than replying  
>>> to
>>> the old one, but for some reason Google Groups wouildn't let me  
>>> reply
>>> to the old one.  The suggestion was that the jQuery documentation be
>>> reworded so that $.browser not be called 'Deprecated', but that its
>>> usage perhaps be discouraged.  I'd strongly support this rewording,
>>> John et al... could we please see it in the next version of the  
>>> jQuery
>>> docs?
>>>
>>> I'm not sure I'd even go as far as 'strongly discouraging' the use  
>>> of
>>> this property; sometimes it's a lot quicker and more convenient to  
>>> use
>>> it than feature detection, and/or the feature detection just isn't
>>> there.  For instance I'm developing a webpage and I happen to know
>>> that IE7 doesn't support the 'before' or 'after' pseudo  
>>> selectors... I
>>> just want to detect whether this is IE7 and behave accordingly, as I
>>> can leave the other browsers alone and not need to emulate this  
>>> css in
>>> Javascript.  So for this reason I'd really like to see things  
>>> reworded
>>> as something like 'please try to use $.support, but this can be used
>>> if necessary;.  Also I'd like to see that word Deprecated dropped;  
>>> it
>>> has a particular meaning in programming, which generally implies  
>>> that
>>> it has been 100% obsoleted by something else and may well be dropped
>>> in a future release.  I don't think this applies or should apply to
>>> $.browser, so it should not be called Deprecated.
>>>
>>> Best regards,
>>> Jeremy Morton (Jez)
>>>
>>> On Jul 6, 4:02 pm, John Resig <jere...@...> 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...@...> wrote:
>>>>> As of 1.3 $.browseris 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,
>>>>> $.browserand 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 $.browserwas 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- 
>>>>> ...
>>>
>>>>> 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@...
>> To unsubscribe from this group, send email to jquery-dev+unsubscribe@...
>> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
>> -~----------~----~----~----~------~----~------~--~---
>>
>>
>
> --
>
> 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@....
> To unsubscribe from this group, send email to jquery-dev+unsubscribe@...
> .
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en 
> .
>
>

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[dave.methvin]

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 suggestion was that the jQuery documentation be
> reworded so that $.browser not be called 'Deprecated',
> but that its usage perhaps be discouraged.

Take a look at http://dev.jquery.com/ticket/2661 . What better way to
discourage its use than to have it return bad information? ;-) If
$.browser remains in jQuery, people expect it to be "correct" for
their definition of correct. Perhaps another round of patches in 1.4
can make it work well enough that there won't be tons of additional
bugs reported against it, but I kind of doubt it. If it can't be fixed
then I think it *should* be removed.

You could argue that $.browser should use feature detection to guess
browsers instead of userAgent, but that just opens a different can of
worms. Consider http://dev.jquery.com/ticket/5391 . If Chrome and
Safari essentially use the same core engine, should they be treated as
a single browser or as different browsers? To answer that, you need to
know if $.browser users are trying to detect the browser brand name,
the browser rendering engine, or infer particular browser capabilities
based on their own experimental observations.

These dilemmas go away if you use feature detection or conditional
comments instead of $.browser, because *you* know what you were really
trying to get at. Or, craft your own detection based on the presence a
feature you think is a good proxy for the feature you can't detect
directly.

> For instance I'm developing a webpage and I happen to know
> that IE7 doesn't support the 'before' or 'after' pseudo selectors...

It seems like it could be feature-detected with a small load-time test
case with an element and some CSS to determine whether those pseudo
selectors work. Or, just use conditional comments in your code if it's
really IE-specific.





--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[jez9999]

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 docs, could we please change the
$.browser docs to reflect something similar to what Dave has said
here?  Say that the browser detection is actually unreliable as
browsers can and do lie about their model and version, and plugins
change browser version strings too, and also emphasize that you can
test for most things (eg. support for even individual CSS pseudo-
selectors) so you shouldn't need it.  Also point to various docs on
how to test for various things that you may wish to test for, because
I had to say I had no idea you could test for that.  :-)

Finally, I would suggest that even if $.browser is removed someday,
these docs I'm suggesting stick around forever, just to tell people
how they can achieve what they want instead without using (unreliable)
browser version detection.

Sooo... Could we at least change the docs in this way please?  :-)

Best regards,
Jeremy Morton (Jez)

On Oct 29, 5:14 pm, Dave Methvin <dave.meth...@...> wrote:

> 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 suggestion was that the jQuery documentation be
> > reworded so that $.browser not be called 'Deprecated',
> > but that its usage perhaps be discouraged.
>
> Take a look athttp://dev.jquery.com/ticket/2661. What better way to
> discourage its use than to have it return bad information? ;-) If
> $.browser remains in jQuery, people expect it to be "correct" for
> their definition of correct. Perhaps another round of patches in 1.4
> can make it work well enough that there won't be tons of additional
> bugs reported against it, but I kind of doubt it. If it can't be fixed
> then I think it *should* be removed.
>
> You could argue that $.browser should use feature detection to guess
> browsers instead of userAgent, but that just opens a different can of
> worms. Considerhttp://dev.jquery.com/ticket/5391. If Chrome and
> Safari essentially use the same core engine, should they be treated as
> a single browser or as different browsers? To answer that, you need to
> know if $.browser users are trying to detect the browser brand name,
> the browser rendering engine, or infer particular browser capabilities
> based on their own experimental observations.
>
> These dilemmas go away if you use feature detection or conditional
> comments instead of $.browser, because *you* know what you were really
> trying to get at. Or, craft your own detection based on the presence a
> feature you think is a good proxy for the feature you can't detect
> directly.
>
> > For instance I'm developing a webpage and I happen to know
> > that IE7 doesn't support the 'before' or 'after' pseudo selectors...
>
> It seems like it could be feature-detected with a small load-time test
> case with an element and some CSS to determine whether those pseudo
> selectors work. Or, just use conditional comments in your code if it's
> really IE-specific.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Michael Geary-3]

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, but what you just mentioned would be a pretty good addition right there.

-Mike

On Thu, Oct 29, 2009 at 11:09 AM, jez9999 <jez9999@...> wrote:

In the next incarnation of jQuery docs, could we please change the
$.browser docs to reflect something similar to what Dave has said
here?

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[jez9999]

OK, I've made a couple of edits to remove the 'deprecated'
connotation.  The updated version's at:
http://docs.jquery.com/Utilities/jQuery.browser

Is it OK?

Best regards,
Jeremy Morton (Jez)

On Nov 4, 12:02 am, Michael Geary <m...@...> wrote:

> 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, but what you just mentioned would be a pretty good addition right
> there.
>
> -Mike
>
> On Thu, Oct 29, 2009 at 11:09 AM, jez9999 <jez9...@...> wrote:
> > In the next incarnation of jQuery docs, could we please change the
> > $.browser docs to reflect something similar to what Dave has said
> > here?

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[John Resig]

I've re-worded it a bit more and removed some extra lines from the end
to make it clearer overall.

--John



On Fri, Nov 6, 2009 at 5:37 PM, jez9999 <jez9999@...> wrote:

> OK, I've made a couple of edits to remove the 'deprecated'
> connotation.  The updated version's at:
> http://docs.jquery.com/Utilities/jQuery.browser
>
> Is it OK?
>
> Best regards,
> Jeremy Morton (Jez)
>
> On Nov 4, 12:02 am, Michael Geary <m...@...> wrote:
>> 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, but what you just mentioned would be a pretty good addition right
>> there.
>>
>> -Mike
>>
>> On Thu, Oct 29, 2009 at 11:09 AM, jez9999 <jez9...@...> wrote:
>> > In the next incarnation of jQuery docs, could we please change the
>> > $.browser docs to reflect something similar to what Dave has said
>> > here?
>
> --
>
> 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@....
> To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
>
>
>

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.