Newly revised Section 10 for ES3.1.

[Allen Wirfs-Brock]

>> It seems like that would be at least as much worth trying as is "make
something that's actively incompatible with all 4 browsers", no?

I'd love to see a proposal

>> I can only presume that you're joking here.

Not really, if you have to change something it may be better to do it in a way that breaks all existing uses rather than just some of them.  It isn't obvious that either the FF or IE approach to function declarations in conditional blocks is "better" or more correct.  Arguments can be made on both design choices. In such a situation, the best solution may actually be to break both of them rather than breaking only one of them.  Particularly, if there is a strong argument that the new design is better than either of the existing ones.

>> FWIW, this sort of thing is a reason that I'm pretty concerned about
ES3.1 getting into an advanced specification state without the benefit
of any in-browser implementation.

You need to have an advance specification state before you can meaningfully test it in an implementation.

-----Original Message-----
From: Mike Shaver [mailto:mike.shaver at gmail.com]
Sent: Wednesday, July 09, 2008 9:49 PM
To: Allen Wirfs-Brock
Cc: Maciej Stachowiak; Herman Venter; Mark S. Miller; es3.x-discuss at mozilla.org; es4-discuss at mozilla.org
Subject: Re: Newly revised Section 10 for ES3.1.

2008/7/10 Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com>:
> Even if we can craft a
> specification that just captured those aspects of block nest function
> declarations that are identical in the 4 principal browsers would It's not
> clear that anybody would  be very happy with the result.

It seems like that would be at least as much worth trying as is "make
something that's actively incompatible with all 4 browsers", no?

> Arguably, one "advantage" of my proposal is that it equally breaks
> all the existing implementations of block nested function declarations.

I can only presume that you're joking here.

FWIW, this sort of thing is a reason that I'm pretty concerned about
ES3.1 getting into an advanced specification state without the benefit
of any in-browser implementation.

Mike