W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2009

Re: Conflicts between W3C specs and ES5?

From: Brendan Eich <brendan@mozilla.org>
Date: Tue, 17 Nov 2009 07:32:38 -0800
Cc: James Graham <jgraham@opera.com>, "Mark S. Miller" <erights@google.com>, public-script-coord@w3.org
Message-Id: <88C981CF-1088-4BF8-9767-858362E6D710@mozilla.org>
To: Maciej Stachowiak <mjs@apple.com>
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? In principle it should be,  
since it was required for web compatibility according to V8  
developers' testing.

> 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  


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  

> Let's save our outrage for features that actually break conceptual  
> integrity of the language, rather than just being slightly lame.

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?

Anyway, we didn't slow ES5 down for the stuff on the wiki page, and I  
do not think we should have delayed it one day.

> 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).

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).

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:


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.

Property Enumeration is an ongoing issue in Ecma TC39. I believe you  
did some useful testing and posted results to es-discuss. Anyway, I'm  
not picking on everything in the wiki page, and probably Mark was not  
either. He was on the look-out for stuff to spec in Ecma, and probably  
for stuff we want to deprecate, at a guess. I'm with him on that last  

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.

IIRC, you objected after the fact that ES5 (3.1 at the time) didn't  
standardize my fine old hacks (these all came from Mozilla about ten  
years ago). I think you were too late, and although I agree in general  
de-facto beats a de-jure "cleanup" that incompatibly innovates, I'd  
say ES5's APIs are "better enough" that the design-by-(sub-)committee  
exercise led by Allen Wirfs-Brock worked, this time. But this is not a  
clean situation and I don't (and didn't) moralize about it.

The argument I was having, which you kindly interrupted (no  
problem! ;-), was against indefinite and blind over-specification. The  
wiki page is a mix, as you say. But only some of it fits in ECMA-262.  
Where does the rest, if we agree to cut the crazy over-specification,  

Received on Tuesday, 17 November 2009 15:33:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:01 UTC