Question

I ran JSLint on some inherited code, and received the following:

Problem at line 24 character 36: Unexpected '\'.

content = content.replace(/\<a href=/g, '<a target="blank" href=');

I’ve been Googling for a while and found this which suggests that I don’t have to escape less thans in a Javascript replace.

HTML += '<div class="articleBody">' 
    + this.myData.record[0][0][5].replace(/<\/?a[^>]*>/gi,'') + '</div>';

But my standard regExp intro would suggest they do, as do some other random sites, that last even talking specifically about Javascript (though its own examples suggest JSLink is right).

The next assertion characters match at the beginning and end of a
word, they are:

< and >

Though Mozilla’s pages (replace() and RegExp) don’t say it does do assertions with < & >, I’ve been unable to find a place that explicitly says Javascript intentionally doesn’t do assertions with < in its RegExp/replace method. That is, I haven’t found anywhere that says a Javascript implementation that escapes < is wrong. And, indeed, the escaped or unescaped < seems to work fine. Admittedly any escaped char that isn’t reserved seems to work fine — for example, \e === e, though \t !== t wrt replace().

Aside: I do realize that not all RegExp implementations are equal, and realize Javascript doesn’t do, for example, look-behind. But that’s pretty common knowledge. The assertions I’m having a harder time finding.

Can someone put this to bed for me? Is there someplace to find that It Is Written that < is intentionally ignored as a marker of an assertion in Javascript RegExp and that anything to the contrary is incorrect behavior?

Answer 1

JSLint is lint, it tells you your code is problematic (according to the author’s standard), but that does not mean your code is semantically wrong. People escape < and > to avoid the piece of Javascript code being interpreted as HTML, although escaping < in your case is useless.

It is guaranteed that, in JS Regex, \< is equivalent to <. (ECMA-262 §15.10.2, IdentityEscape). Basically, any non-alphanumerics escaped are equal to itself. (However, \e does not seem to be defined in the standard.) It is unrelated to assertions (?<=…).