On Sat, Nov 13, 2010 at 8:41 AM, Geoffrey Sneddon <[email protected]>wrote:
> On 27/10/10 21:38, Brendan Eich wrote: > >> Is there consensus that this is defacto standard behavior that is needed >>> for interoperability among browsers and that it should be incorporated into >>> Harmony? >>> >> >> I suspect this is a de-facto standard we should codify in Harmony. Thanks >> for bringing it up. >> > > How much of de-facto standards are going to be codified? What about things > which aren't entirely interoperability implemented, but the basic premise is > an absolute requirement for web compatibility (e.g., the recent thread on > function hoisting). What about things which are needed for web > compatibility, interoperability implemented, but disallowed in ES5/Strict > (e.g., Function.arguments, Function.caller, octal escapes (which are defined > differently to all impls as raised before ES5 was finalized), etc.)? > > I'd very much like to get to a point where you can implement something web > compatible from the spec, which would mean defining things some don't like, > and changing other definitions that people don't like either… At the moment, > it's impossible to implement a fully compliant ES5 implementation without > sacrificing web compatibility. > That may be -- I do know of one example (parseInt), which IMO we should therefore add to the ES5 errata. But **none** of the examples you give are conflicts between ES5 and legacy web compat, since legacy web code doesn't say "use strict". Rather, your examples are ways in which ES5/non-strict is a compatible subset of de-facto cross browser JavaScript. As for codifying the rest of de-factp cross-browser JavaScript, that is the role of Appendix B of the ES5 spec. If Harmony includes a successor to appendix B for codying de fact ES5/non-strict behavior, I agree it might make sense to include Function.arguments, Function.caller, octal escapes, and the items at <http://code.google.com/p/es-lab/source/browse/trunk/src/ses/whitelist.js> that are marked "non-standard" or "whatwg". Note that Harmony itself is a successor only to ES5/strict, so any such enhancements to the codification of ES5/non-strict should stay in an appendix. > > -- > Geoffrey Sneddon — Opera Software > <http://gsnedders.com> > <http://opera.com> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
