On Feb 10, 2009, at 6:34 AM, David-Sarah Hopwood wrote:
> Brendan Eich wrote:
> > On Feb 9, 2009, at 9:42 AM, Marcel Laverdet wrote:
> >
> >> From what I remember this started out as a bug in IE and then
> >> Firefox followed suit for compatibility which left the other
> >> browsers with no choice.
> >
> > No, other browsers followed suit first.
> >
> >> I can't find the original bug but `/[/]/` only started parsing in
> >> FF1.5, in FF1.0 it would throw a syntax error.
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=309840
>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=309840#c12>
>
> # This fixes a highly dup'ed IE compatibility bug. It's an extension
> # to ECMA syntax that's allowed by Section 16. I'm approving it so
> # that we can get it into 1.8b5 / Firefox 1.5b2.
>
> As the example in my first post demonstrated, it is absolutely not
> correct that this was an allowed Section 16 extension.
>
You're right, but so what? The IE bug and monopoly combined to create
a de-facto standard. Appealing to the de-jure standard does you no
good, and correcting my 2005-ear misunderstanding (you've corrected it
more recently in es-discuss) does not change the de-facto standard
trumping the de-jure one.

> In fact this just makes me even more worried: it seems that Section 16
> is being misinterpreted in a way that prevents independently developed
> parsers, implemented strictly from the spec, from being able to
> match the
> parsing behaviour of browsers on syntactically valid ES3 code. Is this
> just a one-off mistake, or is Section 16 consistently being
> interpreted
> too loosely?
>

This has nothing to do with Section 16 or my former misunderstanding
of it, and everything to do with IE forcing a de-facto standard. As
far as I know, no one at Microsoft added the bug allowing unescaped /
in a character class by arguing based on a misinterpretation of
Section 16. I think you are barking up the wrong tree.

/be
>
>
> --
> David-Sarah Hopwood ⚥
>
>
>