Re: Conflicts between W3C specs and ES5?

On Nov 17, 2009, at 7:32 AM, 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? In principle it should  
> be, since it was required for web compatibility according to V8  
> developers' testing.

You'd have to ask the authors of the page that. I assume it's because  
the page constitutes scratch notes and is not exhaustive.

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

I'm personally fine with specifying this kind of functionality at the  
HTML level. But is it appropriate for a spec layered on top of  
ECMAScript to add methods to String.prototype?

>
>> 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?

Is it economically worthwhile evangelizing away the String.prototype  
functions, relative to the cost of specifying them (since they are  
already interoperably implemented)?

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

As far as I can tell, no one has argued that you should have. I think  
the relevant question is what, if anything, to do with this info in  
the future.

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

They seem to interoperate enough that you have to implement them. Do  
you believe they can and should be evangelized away?

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

Indeed, and these notes don't even try to define some sort of  
interoperable subset. Regrettably we may want to leave this one alone.

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

Maybe it can get picked up in the next version.

>
> Global scope vs. global |this| is indeed a conflict as Mark said in  
> his original post.

Yep. Hopefully we can find a clever way out of this in the future.

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

It does seem that sites depend on the intersection semantics. Is this  
one to evangelize again?

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

So you think it's appropriate for a W3C spec to add to the lexical  
syntax? I think it's been previously assumed this would be a bad idea.  
Note that it's not completely HTML-specific because JavaScript in an  
SVG <script> element, or in an external script, or (as far as I know)  
passed to eval()

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

I think he was concerned that there were other unflagged direct  
conflicts between HTML5 (or other W3C specs) and ES5, hopefully we  
have laid that to rest.

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

I think it's probably fine to leave the pre-standard way of doing  
getters and setters behind, assuming we can clear away any actual uses.

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

If it was still 3.1 at the time, then that was hardly after the fact.  
But I'm not actually sure what you're referring to. I think I  
generally advocated for specifying de facto behavior and in particular  
for not having the spec require things contrary to de facto behavior,  
but I don't believe I made a bright line principle.

> 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, belong?

I think the argument you were having was against a position that no  
one has taken.

Regards,
Maciej

Received on Tuesday, 17 November 2009 19:04:30 UTC