<?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: Browser Detection In JavaScript Libraries</title>
	<atom:link href="http://robert.accettura.com/blog/2009/11/30/browser-detection-in-javascript-libraries/feed/" rel="self" type="application/rss+xml" />
	<link>http://robert.accettura.com/blog/2009/11/30/browser-detection-in-javascript-libraries/</link>
	<description>Robert Accettura&#039;s Personal Blog on Web Development and Tech</description>
	<lastBuildDate>Sat, 20 Mar 2010 05:51:39 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Simon</title>
		<link>http://robert.accettura.com/blog/2009/11/30/browser-detection-in-javascript-libraries/comment-page-1/#comment-830789</link>
		<dc:creator>Simon</dc:creator>
		<pubDate>Tue, 01 Dec 2009 20:09:52 +0000</pubDate>
		<guid isPermaLink="false">http://robert.accettura.com/?p=3084#comment-830789</guid>
		<description>@Robert - if the problem is people running older, poorly performing versions of Flash, I can&#039;t see that you can do much about that. But what&#039;s your fallback in the second case, for users without Flash, or without a good enough version? If the fallback is a good option (e.g HTML5 video), why is it not the first choice if supported? And if it&#039;s not a good option, why force Linux users onto an inferior choice when they *might* have a perfectly workable Flash?

Seriously, if a good enough Flash plugin is available on Linux, why not just assume that everyone has it? If 10 is that much better than previous versions, surely anyone who actually cares about Flash will have it?</description>
		<content:encoded><![CDATA[<p>@Robert &#8211; if the problem is people running older, poorly performing versions of Flash, I can&#8217;t see that you can do much about that. But what&#8217;s your fallback in the second case, for users without Flash, or without a good enough version? If the fallback is a good option (e.g HTML5 video), why is it not the first choice if supported? And if it&#8217;s not a good option, why force Linux users onto an inferior choice when they *might* have a perfectly workable Flash?</p>
<p>Seriously, if a good enough Flash plugin is available on Linux, why not just assume that everyone has it? If 10 is that much better than previous versions, surely anyone who actually cares about Flash will have it?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert</title>
		<link>http://robert.accettura.com/blog/2009/11/30/browser-detection-in-javascript-libraries/comment-page-1/#comment-830687</link>
		<dc:creator>Robert</dc:creator>
		<pubDate>Tue, 01 Dec 2009 14:23:02 +0000</pubDate>
		<guid isPermaLink="false">http://robert.accettura.com/?p=3084#comment-830687</guid>
		<description>@Neil Rashbrook: I believe &lt;code&gt;.tolowercase()&lt;/code&gt; once would actually be quicker than multiple case insensitive regular expressions.</description>
		<content:encoded><![CDATA[<p>@Neil Rashbrook: I believe <code>.tolowercase()</code> once would actually be quicker than multiple case insensitive regular expressions.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert</title>
		<link>http://robert.accettura.com/blog/2009/11/30/browser-detection-in-javascript-libraries/comment-page-1/#comment-830686</link>
		<dc:creator>Robert</dc:creator>
		<pubDate>Tue, 01 Dec 2009 14:21:03 +0000</pubDate>
		<guid isPermaLink="false">http://robert.accettura.com/?p=3084#comment-830686</guid>
		<description>@Simon: Not exactly.  As far as I know you can&#039;t do capability detection to see if Flash performance.  Knowing that nothing less than Flash 10 is usable on Linux for the vast majority of users, what is an alternate way to provide:

1. Experience to Flash 8+ users on all platforms, and Flash 10+ on Linux.
2. Experience to non-flash and Linux users with Flash 9 or below.


Another thing you can&#039;t detect correctly via feature detection is font handling.  Linux and Mac (especially Mac OS 10.4 with default anti-aliasing) fonts at sizes &lt; 8px don&#039;t appear as readable as they do on Windows XP/Vista/7.  The best solution available other than change the design (not always possible depending on designer) is to up the font size per platform.</description>
		<content:encoded><![CDATA[<p>@Simon: Not exactly.  As far as I know you can&#8217;t do capability detection to see if Flash performance.  Knowing that nothing less than Flash 10 is usable on Linux for the vast majority of users, what is an alternate way to provide:</p>
<p>1. Experience to Flash 8+ users on all platforms, and Flash 10+ on Linux.<br />
2. Experience to non-flash and Linux users with Flash 9 or below.</p>
<p>Another thing you can&#8217;t detect correctly via feature detection is font handling.  Linux and Mac (especially Mac OS 10.4 with default anti-aliasing) fonts at sizes &lt; 8px don&#039;t appear as readable as they do on Windows XP/Vista/7.  The best solution available other than change the design (not always possible depending on designer) is to up the font size per platform.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arthur Kay</title>
		<link>http://robert.accettura.com/blog/2009/11/30/browser-detection-in-javascript-libraries/comment-page-1/#comment-830685</link>
		<dc:creator>Arthur Kay</dc:creator>
		<pubDate>Tue, 01 Dec 2009 14:16:34 +0000</pubDate>
		<guid isPermaLink="false">http://robert.accettura.com/?p=3084#comment-830685</guid>
		<description>Great job! This is probably the best explanation of the various JS frameworks I&#039;ve seen with regards to this feature (browser sniffing). I would have loved to see how ExtJS fits into the mix... maybe you could add that with a follow-up post.

The one thing I consistently don&#039;t like about YUI is their naming conventions. The namespace titles and local variables are named so generically that it&#039;s often difficult to follow the thought process. ExtJS is also sometimes guilty of that (at least with the local variables), though I suppose it could be a result of Yahoo/Ext using JavaScript code compression.

Lastly, I must say that I hate the fact that OS/Browser detection is even used. I won&#039;t go as far as to say that there&#039;s never a reason to use it, but generally speaking a good web developer will do everything humanly possible to avoid it. It&#039;s like using the NOSCRIPT tags or hacking CSS for IE6 - you need to know who your users are and build a tool that supports their hardware (not the other way around).</description>
		<content:encoded><![CDATA[<p>Great job! This is probably the best explanation of the various JS frameworks I&#8217;ve seen with regards to this feature (browser sniffing). I would have loved to see how ExtJS fits into the mix&#8230; maybe you could add that with a follow-up post.</p>
<p>The one thing I consistently don&#8217;t like about YUI is their naming conventions. The namespace titles and local variables are named so generically that it&#8217;s often difficult to follow the thought process. ExtJS is also sometimes guilty of that (at least with the local variables), though I suppose it could be a result of Yahoo/Ext using JavaScript code compression.</p>
<p>Lastly, I must say that I hate the fact that OS/Browser detection is even used. I won&#8217;t go as far as to say that there&#8217;s never a reason to use it, but generally speaking a good web developer will do everything humanly possible to avoid it. It&#8217;s like using the NOSCRIPT tags or hacking CSS for IE6 &#8211; you need to know who your users are and build a tool that supports their hardware (not the other way around).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ¿Como detectan el navegador los diferentes frameworks Javascript? : Blogografia</title>
		<link>http://robert.accettura.com/blog/2009/11/30/browser-detection-in-javascript-libraries/comment-page-1/#comment-830668</link>
		<dc:creator>¿Como detectan el navegador los diferentes frameworks Javascript? : Blogografia</dc:creator>
		<pubDate>Tue, 01 Dec 2009 13:00:35 +0000</pubDate>
		<guid isPermaLink="false">http://robert.accettura.com/?p=3084#comment-830668</guid>
		<description>[...] estos casos, saber como lo hacen los frameworks Javascript más usados nos permitirá hacernos una idea de como actuar frente a este [...]</description>
		<content:encoded><![CDATA[<p>[...] estos casos, saber como lo hacen los frameworks Javascript más usados nos permitirá hacernos una idea de como actuar frente a este [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Neil Rashbrook</title>
		<link>http://robert.accettura.com/blog/2009/11/30/browser-detection-in-javascript-libraries/comment-page-1/#comment-830603</link>
		<dc:creator>Neil Rashbrook</dc:creator>
		<pubDate>Tue, 01 Dec 2009 10:30:15 +0000</pubDate>
		<guid isPermaLink="false">http://robert.accettura.com/?p=3084#comment-830603</guid>
		<description>For your OS detection for jQuery I would suggest using the /i regexp flag like YUI does.</description>
		<content:encoded><![CDATA[<p>For your OS detection for jQuery I would suggest using the /i regexp flag like YUI does.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mook</title>
		<link>http://robert.accettura.com/blog/2009/11/30/browser-detection-in-javascript-libraries/comment-page-1/#comment-830485</link>
		<dc:creator>Mook</dc:creator>
		<pubDate>Tue, 01 Dec 2009 05:53:33 +0000</pubDate>
		<guid isPermaLink="false">http://robert.accettura.com/?p=3084#comment-830485</guid>
		<description>For the jquery os detection, wouldn&#039;t using navigator.platform make more sense?  Or are you explicitly allowing the user to override it?

(Also, Flash runs much better on my Linux machine compared to my Windows one.  Probably because it is two years newer and has ten times the RAM, and a standalone video card.  Just means you really need to let the user tell you things.)</description>
		<content:encoded><![CDATA[<p>For the jquery os detection, wouldn&#8217;t using navigator.platform make more sense?  Or are you explicitly allowing the user to override it?</p>
<p>(Also, Flash runs much better on my Linux machine compared to my Windows one.  Probably because it is two years newer and has ten times the RAM, and a standalone video card.  Just means you really need to let the user tell you things.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon</title>
		<link>http://robert.accettura.com/blog/2009/11/30/browser-detection-in-javascript-libraries/comment-page-1/#comment-830469</link>
		<dc:creator>Simon</dc:creator>
		<pubDate>Tue, 01 Dec 2009 04:14:04 +0000</pubDate>
		<guid isPermaLink="false">http://robert.accettura.com/?p=3084#comment-830469</guid>
		<description>@Robert - again, wrong approach. Firstly, you&#039;re making a decision that Flash will never be good enough on Linux, and the user should never use it. If in six months a new flash player comes out that works properly, well, too bad - you&#039;ve decided Linux users can&#039;t use it.

Second, it there&#039;s something else that works better for a particular OS, is there a reason you&#039;re not using it anywhere else? HTML5 video, say - if that&#039;s better than Flash for Linux users, is it also better than Flash for Windows and Mac users? And if so, we&#039;re back to capability detection again - if something supports native video, use that, else fall back to Flash...</description>
		<content:encoded><![CDATA[<p>@Robert &#8211; again, wrong approach. Firstly, you&#8217;re making a decision that Flash will never be good enough on Linux, and the user should never use it. If in six months a new flash player comes out that works properly, well, too bad &#8211; you&#8217;ve decided Linux users can&#8217;t use it.</p>
<p>Second, it there&#8217;s something else that works better for a particular OS, is there a reason you&#8217;re not using it anywhere else? HTML5 video, say &#8211; if that&#8217;s better than Flash for Linux users, is it also better than Flash for Windows and Mac users? And if so, we&#8217;re back to capability detection again &#8211; if something supports native video, use that, else fall back to Flash&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert</title>
		<link>http://robert.accettura.com/blog/2009/11/30/browser-detection-in-javascript-libraries/comment-page-1/#comment-830467</link>
		<dc:creator>Robert</dc:creator>
		<pubDate>Tue, 01 Dec 2009 04:04:35 +0000</pubDate>
		<guid isPermaLink="false">http://robert.accettura.com/?p=3084#comment-830467</guid>
		<description>@Simon: Totally not true.  AFAIK no Flash implementation on Linux is really a top notch experience (Windows is solid, Mac is now tolerable).  Performance is still not very good (rather serve an other format video for Linux users).  Also have seen issues with copy/paste via those flash/js solutions.  

It&#039;s a much better solution to ship something that works than to tell people &quot;use Windows if you want it to work&quot; as you seem to suggest.</description>
		<content:encoded><![CDATA[<p>@Simon: Totally not true.  AFAIK no Flash implementation on Linux is really a top notch experience (Windows is solid, Mac is now tolerable).  Performance is still not very good (rather serve an other format video for Linux users).  Also have seen issues with copy/paste via those flash/js solutions.  </p>
<p>It&#8217;s a much better solution to ship something that works than to tell people &#8220;use Windows if you want it to work&#8221; as you seem to suggest.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://robert.accettura.com/blog/2009/11/30/browser-detection-in-javascript-libraries/comment-page-1/#comment-830466</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Tue, 01 Dec 2009 03:52:40 +0000</pubDate>
		<guid isPermaLink="false">http://robert.accettura.com/?p=3084#comment-830466</guid>
		<description>I agree with Simon on all points.  That these libraries include browser detection at all seems like a bug, except insofar as it internally lets them work around known bugs with no other possible workaround, and even then they shouldn&#039;t expose that outside the library.  Furthermore, doing feature detection for the purpose of browser detection, with the expectation that people will then use the browser detection results, seems much worse.</description>
		<content:encoded><![CDATA[<p>I agree with Simon on all points.  That these libraries include browser detection at all seems like a bug, except insofar as it internally lets them work around known bugs with no other possible workaround, and even then they shouldn&#8217;t expose that outside the library.  Furthermore, doing feature detection for the purpose of browser detection, with the expectation that people will then use the browser detection results, seems much worse.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
