<?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"
	>
<channel>
	<title>Comments on: ECMAScript 3 Regular Expressions: A specification that doesn&#8217;t make sense</title>
	<atom:link href="http://web-graphics.com/2007/11/26/ecmascript-3-regular-expressions-a-specification-that-doesnt-make-sense/feed/" rel="self" type="application/rss+xml" />
	<link>http://web-graphics.com/2007/11/26/ecmascript-3-regular-expressions-a-specification-that-doesnt-make-sense/</link>
	<description>Web development concerns, usually revolving around implimentation of designs into graphics, CSS, and HTML.</description>
	<pubDate>Sun, 20 Jul 2008 23:39:40 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Steven Levithan</title>
		<link>http://web-graphics.com/2007/11/26/ecmascript-3-regular-expressions-a-specification-that-doesnt-make-sense/#comment-22195</link>
		<dc:creator>Steven Levithan</dc:creator>
		<pubDate>Mon, 26 Nov 2007 16:36:01 +0000</pubDate>
		<guid isPermaLink="false">http://web-graphics.com/2007/11/26/ecmascript-3-regular-expressions-a-specification-that-doesnt-make-sense/#comment-22195</guid>
		<description>Thanks for fighting the good fight, liorean. These spec bugs need to be fixed. However, I disagree that both changes are safe. The case of making backreferences to non-participating capturing groups match the empty string rather than fail to match (as ES3 prescribes) is respected by the latest versions of Firefox, IE, and Opera. Safari 3.0.3 beta and lower handles it the more sensible, Perl-compatible way, but this will change in later versions of Safari (see http://bugs.webkit.org/show_bug.cgi?id=14931 ). Unfortunately, some JavaScripters who are not deeply familiar with regexes tend to stumble around when constructing a regex until something works, without necessarily understanding why. It is these cases that have potential to break if ES4 fixes the problem. However, it is likely only these cases since the ES3 handling is never actually intuitive or desirable.</description>
		<content:encoded><![CDATA[<p>Thanks for fighting the good fight, liorean. These spec bugs need to be fixed. However, I disagree that both changes are safe. The case of making backreferences to non-participating capturing groups match the empty string rather than fail to match (as ES3 prescribes) is respected by the latest versions of Firefox, IE, and Opera. Safari 3.0.3 beta and lower handles it the more sensible, Perl-compatible way, but this will change in later versions of Safari (see <a href="http://bugs.webkit.org/show_bug.cgi?id=14931" rel="nofollow">http://bugs.webkit.org/show_bug.cgi?id=14931</a> ). Unfortunately, some JavaScripters who are not deeply familiar with regexes tend to stumble around when constructing a regex until something works, without necessarily understanding why. It is these cases that have potential to break if ES4 fixes the problem. However, it is likely only these cases since the ES3 handling is never actually intuitive or desirable.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
