<?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: And the winner is…</title>
	<atom:link href="http://www.ardisson.org/afkar/2010/02/07/and-the-winner-is%e2%80%a6-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.ardisson.org/afkar/2010/02/07/and-the-winner-is%e2%80%a6-2/</link>
	<description>A journal at al-Qâhira fî Amrîkâ</description>
	<lastBuildDate>Fri, 13 Jan 2012 20:41:10 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Colby Russell</title>
		<link>http://www.ardisson.org/afkar/2010/02/07/and-the-winner-is%e2%80%a6-2/comment-page-1/#comment-7139</link>
		<dc:creator>Colby Russell</dc:creator>
		<pubDate>Tue, 09 Feb 2010 03:47:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.ardisson.org/afkar/?p=546#comment-7139</guid>
		<description>Worst that can happen is that you lock out users because of an incompetent detection approach.</description>
		<content:encoded><![CDATA[<p>Worst that can happen is that you lock out users because of an incompetent detection approach.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Laurens Holst</title>
		<link>http://www.ardisson.org/afkar/2010/02/07/and-the-winner-is%e2%80%a6-2/comment-page-1/#comment-7137</link>
		<dc:creator>Laurens Holst</dc:creator>
		<pubDate>Mon, 08 Feb 2010 20:28:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.ardisson.org/afkar/?p=546#comment-7137</guid>
		<description>Blogged my above comment at http://www.grauw.nl/blog/entry/542</description>
		<content:encoded><![CDATA[<p>Blogged my above comment at <a href="http://www.grauw.nl/blog/entry/542" rel="nofollow">http://www.grauw.nl/blog/entry/542</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Laurens Holst</title>
		<link>http://www.ardisson.org/afkar/2010/02/07/and-the-winner-is%e2%80%a6-2/comment-page-1/#comment-7135</link>
		<dc:creator>Laurens Holst</dc:creator>
		<pubDate>Mon, 08 Feb 2010 19:53:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.ardisson.org/afkar/?p=546#comment-7135</guid>
		<description>Except that you’re forgetting that browsers tend to implement their new features in a broken way. D’oh.

The node.children.tags() method is a good example. Originally an IE-ism/feature. Then Safari comes along with support for .tags() but returns nodes from the entire document instead of just the child nodes.

Firefox then decided to implement the children collection as well, however without tags() method and thus incompletely, again breaking my feature detection. And finally Opera swings along, throwing an exception when tags() is used in a document parsed as XHTML (iirc).

So after having to fix this stupid optimisation in my Selectors implementation three times, what did I end up doing? Right,

if (browser_ie)
   return node.children.tags(&#039;a&#039;);

Another example is IE8’s broken JSON support, which manages to serialise DOMStrings (e.g. retrieved from getAttribute) to null instead of &quot;&quot;.

Feature detection is overrated. Because of this kind of crap I went back to (a sensible form of) browser detection, with the much more workable presumption that once implemented, browsers will not remove or break existing functionality without at least ample warning. And if they do, at least it is a clear regression.

Worst that can happen is that when the browser updates to include native support for something, it runs a little slower than it could possibly do. Just don’t depend on clearly broken behaviour.</description>
		<content:encoded><![CDATA[<p>Except that you’re forgetting that browsers tend to implement their new features in a broken way. D’oh.</p>
<p>The node.children.tags() method is a good example. Originally an IE-ism/feature. Then Safari comes along with support for .tags() but returns nodes from the entire document instead of just the child nodes.</p>
<p>Firefox then decided to implement the children collection as well, however without tags() method and thus incompletely, again breaking my feature detection. And finally Opera swings along, throwing an exception when tags() is used in a document parsed as XHTML (iirc).</p>
<p>So after having to fix this stupid optimisation in my Selectors implementation three times, what did I end up doing? Right,</p>
<p>if (browser_ie)<br />
   return node.children.tags(&#8216;a&#8217;);</p>
<p>Another example is IE8’s broken JSON support, which manages to serialise DOMStrings (e.g. retrieved from getAttribute) to null instead of &#8220;&#8221;.</p>
<p>Feature detection is overrated. Because of this kind of crap I went back to (a sensible form of) browser detection, with the much more workable presumption that once implemented, browsers will not remove or break existing functionality without at least ample warning. And if they do, at least it is a clear regression.</p>
<p>Worst that can happen is that when the browser updates to include native support for something, it runs a little slower than it could possibly do. Just don’t depend on clearly broken behaviour.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

