<?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: Javascript snippets</title>
	<atom:link href="http://www.klunde.net/2009/06/18/javascript-snippets/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.klunde.net/2009/06/18/javascript-snippets/</link>
	<description>www.klunde.net</description>
	<lastBuildDate>Fri, 05 Mar 2010 07:18:56 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=abc</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Michael Odden</title>
		<link>http://www.klunde.net/2009/06/18/javascript-snippets/comment-page-1/#comment-3398</link>
		<dc:creator>Michael Odden</dc:creator>
		<pubDate>Fri, 19 Jun 2009 11:26:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.klunde.net/?p=302#comment-3398</guid>
		<description>To nice tricks indeed, the rel=&quot;external&quot; is one I&#039;ve used in some situations myself. I don&#039;t really think it&#039;s a hack, as I&#039;ve understood that it&#039;s just the HTML-serialization of the DOM that doesn&#039;t allow targer=&quot;_blank&quot;, but it is valid from a DOM-point-of-view.

An other way to implement this could be (if _all_ other links than the internal ones should be external), to check for the hostname of the href-attribute, and check it against the hostname of the page the script is invoked on. But again this is against my own beliefs that it should be the user who should decide if the link should open in a new page/tab, and not the site. The exception can of course be for links to help-resources etc when in the process of filling out a form or going through a multi-page-order-sequence etc.

I liked the implementation of the email-trick, as it falls back to a readable email-address if JS is not supported (long live progressive enhancement ;) ). But I do also believe that spambots are learning the alternative ways of formatting email-addresses (&quot;AT&quot;, &quot;DOT&quot; etc), but then again it should atleast filter out some of them :).</description>
		<content:encoded><![CDATA[<p>To nice tricks indeed, the rel=&#8221;external&#8221; is one I&#8217;ve used in some situations myself. I don&#8217;t really think it&#8217;s a hack, as I&#8217;ve understood that it&#8217;s just the HTML-serialization of the DOM that doesn&#8217;t allow targer=&#8221;_blank&#8221;, but it is valid from a DOM-point-of-view.</p>
<p>An other way to implement this could be (if _all_ other links than the internal ones should be external), to check for the hostname of the href-attribute, and check it against the hostname of the page the script is invoked on. But again this is against my own beliefs that it should be the user who should decide if the link should open in a new page/tab, and not the site. The exception can of course be for links to help-resources etc when in the process of filling out a form or going through a multi-page-order-sequence etc.</p>
<p>I liked the implementation of the email-trick, as it falls back to a readable email-address if JS is not supported (long live progressive enhancement <img src='http://www.klunde.net/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' />  ). But I do also believe that spambots are learning the alternative ways of formatting email-addresses (&#8220;AT&#8221;, &#8220;DOT&#8221; etc), but then again it should atleast filter out some of them <img src='http://www.klunde.net/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> .</p>
]]></content:encoded>
	</item>
</channel>
</rss>
