Re: Conflicts between W3C specs and ES5?

Brendan Eich wrote:
> On Nov 16, 2009, at 4:28 PM, Maciej Stachowiak wrote:
> 
>>> The opportunity cost (that you spend time on trailing edge stuff 
>>> instead of better leading edge work) is very high too.
>>
>> Did you look at the contents of the Wiki page? foo.arguments is not in 
>> there, nor is anything of a similar level of evil.
> 
> You're right -- I brought foo.arguments up because it is implemented by 
> V8, and based on stealth-mode development combined with web testing. So 
> why isn't it on that wiki page? 

Oversight. It would be good if someone who knows the details could add 
it (with justification about why it is evil and any data you have about 
how pervasive it is, if you like).

>> Many of the things on that page (for example the HTML-formatting 
>> String functions) look like things we should just spec in ECMAScript.
> 
> We tried removing those HTML String.prototype functions once, a while back:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=276030
> 
> These methods are just HTML-oriented extensions, so not objectionable in 
> a standard. But the core language standard, ECMA-262, is used in many 
> domains where HTML processors are missing. If these really should 
> consume scarce specification resources, why not in w3c? Or whatwg, if 
> necessary.

Sure, I would be quite happy with a "web extensions to ECMAScript" 
specification that could be ignored by implementations that don't need 
to work with web content.

> This is not about "evil" or "outrage", it's about economics. How much 
> time should we spend on trailing edge stuff that may be so little used 
> it could be evangelized away?

If we really believe things can be evangelized away then we should do 
that first. If that fails however we should be prepared to document the 
stuff that implementors have to know.

>> You also said (earlier) that the page describes browser differences, 
>> but from my reading many (most?) of the things mentioned are totally 
>> cross-browser compatible, just not specified anywhere yet.
> 
> RegExp statics probably do not interoperate fully (we save, clear, and 
> restore across certain boundaries; other ugly details elude my memory at 
> the moment).

The fact that there are difficult edge cases doesn't change the fact 
that these features are needed by anyone implementing an ECMAScript 
engine for the web. I guess there is interoperability for the majority 
of normal cases.

> Date.parse we've discussed. Non-interoperable mess in detail, many 
> corner cases (IE seems to apply heuristics, not sure whether 
> locale-specific, to mm/dd vs. dd/mm month-day order, for example).
> 
> Date.UTC. I agree that's a small issue, easy to spec -- a bug on ES5 if 
> you will. Too bad it wasn't reported (AFAIK).

Is this enough to be considered a bug report for ES6? Or does es-discuss 
have to be involved?

> Global scope vs. global |this| is indeed a conflict as Mark said in his 
> original post.
> 
> Evil eval (outside of what ES5 specs; and yes, I'm moralizing now, 
> you'll know it when I do :-P) is a non-interoperable zoo, see Pratap 
> Lakshman's "JScript Deviations from ES3" doc:
> 
> http://wiki.ecmascript.org/lib/exe/fetch.php?id=resources%3Aresources&cache=cache&media=resources:jscriptdeviationsfromes3.pdf 

Indeed. This is genuinely a hard case and the best option for authors is 
to not do that, ever. Personally I would prefer to say that the eval in 
this case always happens in the global scope but I wonder if people 
would actually change their implementations on this point.

> HTML comments is a worthwhile spec for someone to construct but again, 
> it seems better left ouf of the core language spec, since it is 
> embedding-domain-specific. Sure, an important embedding, the most 
> important -- but it is separable (ignoring E4X) and probably better 
> dealt with in w3c/whatwg.org as a practical matter.

Agreed.

> Property Enumeration is an ongoing issue in Ecma TC39. I believe you did 
> some useful testing and posted results to es-discuss.

Great.

> Object Properties (__proto__, really) and Getters and Setters were 
> thrown under the bus in favor of ES5's new and better ways of doing most 
> of what these do.

Yet they are still needed for web compatibility today. They also seem 
like ideal fodder for a "Web extensions to ECMAScript" spec.

Received on Tuesday, 17 November 2009 15:53:55 UTC