A DOM use case that can't be emulated with direct proxies
erights at gmail.com
Fri Dec 14 07:54:26 PST 2012
Regarding what Andreas said and what Alex +1ed, we already have precedent.
We already argued through this precedent in committee and agreed. I like
David's suggestion about how to organize these tests.
On Fri, Dec 14, 2012 at 5:22 AM, Alex Russell <slightlyoff at google.com>wrote:
> +1. What Andreas said.
> On Friday, December 14, 2012, Andreas Rossberg wrote:
>> On 13 December 2012 19:21, Mark S. Miller <erights at google.com> wrote:
>> > On Thu, Dec 13, 2012 at 1:12 AM, David Bruant <bruant.d at gmail.com>
>> >>> As you say, to remain viable, it
>> >>> must be done quickly. From previous experience, I suggest that there's
>> >>> exactly one way to get quick universal deployment: add a test to
>> >>> test262 that fails when a browser's WindowProxy object violates this
>> >>> normative part of the ES5 spec.
>> >> I feel such a test would rather belong to the HTML DOM. But either
>> way, I
>> >> agree.
>> > The spec that it violates is ES5.1. Therefore it will be
>> > uncontroversial to put such tests into test262.
>> I have to strongly disagree here. By this argument, we could put in a
>> test for any JS extension in the world that potentially violates
>> proper ES semantics. I think test262 should test ECMA-262, nothing
>> In particular, consider that test262 currently is a headless test,
>> i.e. no browser needed, a shell like d8 or jsc is enough to run it.
>> Putting in browser-specific tests would put a _huge_ burden on all
>> kinds of automated testing environments running this suite.
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
Text by me above is hereby placed in the public domain
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss