<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: In defence of jQuery browser detection</title>
	<atom:link href="http://wheresrhys.co.uk/2009/05/in-defence-of-jquery-browser-detection/feed/" rel="self" type="application/rss+xml" />
	<link>http://wheresrhys.co.uk/2009/05/in-defence-of-jquery-browser-detection/</link>
	<description>on the internet</description>
	<lastBuildDate>Tue, 08 Jun 2010 21:07:59 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Yuvalik</title>
		<link>http://wheresrhys.co.uk/2009/05/in-defence-of-jquery-browser-detection/comment-page-1/#comment-2910</link>
		<dc:creator>Yuvalik</dc:creator>
		<pubDate>Thu, 19 Nov 2009 16:07:30 +0000</pubDate>
		<guid isPermaLink="false">http://wheresrhys.co.uk/?p=605#comment-2910</guid>
		<description>I have been saying exactly that. Although feature detection sounds good, you can never expect it to work 100% for all possible things you are looking for.
How to determine is a browser supports transparent PNG? or @font-face?
It would be nice if it could be done with feature detection, but the truth is, even if it is possible, it creates oodles of code and is just not efficient.
Targeting a browser is -for the time being- much more realistic.
I guess it is one of those hyped ideas that everybody follows without thinking.</description>
		<content:encoded><![CDATA[<p>I have been saying exactly that. Although feature detection sounds good, you can never expect it to work 100% for all possible things you are looking for.<br />
How to determine is a browser supports transparent PNG? or @font-face?<br />
It would be nice if it could be done with feature detection, but the truth is, even if it is possible, it creates oodles of code and is just not efficient.<br />
Targeting a browser is -for the time being- much more realistic.<br />
I guess it is one of those hyped ideas that everybody follows without thinking.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: RistoT</title>
		<link>http://wheresrhys.co.uk/2009/05/in-defence-of-jquery-browser-detection/comment-page-1/#comment-2541</link>
		<dc:creator>RistoT</dc:creator>
		<pubDate>Sat, 24 Oct 2009 18:04:15 +0000</pubDate>
		<guid isPermaLink="false">http://wheresrhys.co.uk/?p=605#comment-2541</guid>
		<description>Even if it goes away, YOU can still use it via a jquery plugin
http://jquery.thewikies.com/browser/</description>
		<content:encoded><![CDATA[<p>Even if it goes away, YOU can still use it via a jquery plugin<br />
<a href="http://jquery.thewikies.com/browser/" rel="nofollow">http://jquery.thewikies.com/browser/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: wheresrhys</title>
		<link>http://wheresrhys.co.uk/2009/05/in-defence-of-jquery-browser-detection/comment-page-1/#comment-811</link>
		<dc:creator>wheresrhys</dc:creator>
		<pubDate>Thu, 18 Jun 2009 09:59:33 +0000</pubDate>
		<guid isPermaLink="false">http://wheresrhys.co.uk/?p=605#comment-811</guid>
		<description>If you&#039;re right, and jQuery.browser is not going away, that&#039;s certainly a good thing, but it does beg the question of why they bothered deprecating it. Probably to prevent people who should be using .support from using it inappropriately... &lt;em&gt;but I say let them&lt;/em&gt;. As jQuery largely hides browser specific javascript tweaks away inside its methods it already is very effective at weaning people away from the habit of checking the browser at every turn. So for jQuery users - who aren&#039;t forced to learn about what js bugs apply in which browsers - it&#039;s certainly easier and more intuitive to check for feature support rather than the browser in most cases.</description>
		<content:encoded><![CDATA[<p>If you&#8217;re right, and jQuery.browser is not going away, that&#8217;s certainly a good thing, but it does beg the question of why they bothered deprecating it. Probably to prevent people who should be using .support from using it inappropriately&#8230; <em>but I say let them</em>. As jQuery largely hides browser specific javascript tweaks away inside its methods it already is very effective at weaning people away from the habit of checking the browser at every turn. So for jQuery users &#8211; who aren&#8217;t forced to learn about what js bugs apply in which browsers &#8211; it&#8217;s certainly easier and more intuitive to check for feature support rather than the browser in most cases.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul Irish</title>
		<link>http://wheresrhys.co.uk/2009/05/in-defence-of-jquery-browser-detection/comment-page-1/#comment-782</link>
		<dc:creator>Paul Irish</dc:creator>
		<pubDate>Fri, 12 Jun 2009 15:29:34 +0000</pubDate>
		<guid isPermaLink="false">http://wheresrhys.co.uk/?p=605#comment-782</guid>
		<description>A few things..

While it does &lt;i&gt;say&lt;/i&gt; deprecated, I&#039;m pretty confident jQuery.browser won&#039;t be going away. You needn&#039;t worry about that, IMHO.

I also admit that, currently, it&#039;s not totally realistic to drop browser sniffs completely. Eric Martin of Simplemodal gave the good example of IE6&#039;s nasty technique of showing select dropdowns through all layers. I don&#039;t think that&#039;s testable.  

However many things are testable so that leads us to these three points...

1) Everyone should agree that feature detection is a better and more robust approach and should extend the jQuery.support object to test for their needs

2) however sometimes it&#039;s not possible to use for what you&#039;re working around

3) and sometimes the test would be too expensive to run from a performance standpoint (though I haven&#039;t seen one yet)</description>
		<content:encoded><![CDATA[<p>A few things..</p>
<p>While it does <i>say</i> deprecated, I&#8217;m pretty confident jQuery.browser won&#8217;t be going away. You needn&#8217;t worry about that, IMHO.</p>
<p>I also admit that, currently, it&#8217;s not totally realistic to drop browser sniffs completely. Eric Martin of Simplemodal gave the good example of IE6&#8217;s nasty technique of showing select dropdowns through all layers. I don&#8217;t think that&#8217;s testable.  </p>
<p>However many things are testable so that leads us to these three points&#8230;</p>
<p>1) Everyone should agree that feature detection is a better and more robust approach and should extend the jQuery.support object to test for their needs</p>
<p>2) however sometimes it&#8217;s not possible to use for what you&#8217;re working around</p>
<p>3) and sometimes the test would be too expensive to run from a performance standpoint (though I haven&#8217;t seen one yet)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andrew Powell</title>
		<link>http://wheresrhys.co.uk/2009/05/in-defence-of-jquery-browser-detection/comment-page-1/#comment-781</link>
		<dc:creator>Andrew Powell</dc:creator>
		<pubDate>Fri, 12 Jun 2009 14:50:53 +0000</pubDate>
		<guid isPermaLink="false">http://wheresrhys.co.uk/?p=605#comment-781</guid>
		<description>Excellent points. Just stumbled across your article. I too, have the need for browser detection in most of the apps I work on professionally. While the supports feature is nice, I agree with you; it doesn&#039;t cover all the bases.</description>
		<content:encoded><![CDATA[<p>Excellent points. Just stumbled across your article. I too, have the need for browser detection in most of the apps I work on professionally. While the supports feature is nice, I agree with you; it doesn&#8217;t cover all the bases.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
