Re: Conflicts between W3C specs and ES5?

On Nov 17, 2009, at 1:16 PM, Brendan Eich wrote:

> On Nov 17, 2009, at 11:03 AM, Maciej Stachowiak wrote:
>
>> 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.
>
> Yes, and since I opened my big mouth about foo.arguments, James now  
> avers that it should be added to that wiki page. So my point stands:  
> it looks like incipient over-specification, specifically of  
> foo.arguments, RegExp statics, Date.parse, non-standard eval,  
> possibly settable __proto__.

The page doesn't make any suggestions about what should be specified,  
or where, it just documents some facts. It's up to us (the Web-related  
standards community) to figure out what to do with this information.

> No big deal, it's just a wiki. But there's a big-picture issue here,  
> to do with trailing edge over-kill vs. alternatives that move the  
> leading edge forward. Sometimes the intersection semantics among  
> browsers for a given API or syntax and semantics are so broken that  
> developers avoid the feature already, and a new-and-better way can  
> be promulgated (not designed by committee, but designed in the open  
> and trial-implemented).
>
> I do not believe we have infinite and pre-specialized labor  
> available (we = all of us reading this, and our colleagues) to both  
> over-specify legacy and try to move forward with better specs.  
> Worse, over-specifying legacy has inherent costs, not only  
> opportunity costs: it can lead to de-jure constraints on future  
> evolution that do not exist, or are not very strongly felt by most  
> developers, at any rate, on the web. Those de-jure constraints can  
> then beget dependent content.
>
> This is why I'm picking on foo.arguments. It's just a convenient  
> devil to whip ;-).

I think browser vendors who are not as confident in flexing their  
market power as Mozilla may make reasonably different tradeoffs in  
this regard. Mozilla folks seem willing and sometimes even eager to  
break content to clean up the platform, the rest of us are more  
reluctant to try to dictate to Web sites. At times, things get left  
unspecified based solely on the hope that one day we can clean them  
out of the platform, and that day may never materialize. That seems to  
hurt smaller-share vendors and new entrants without actually  
benefitting the Web platform. I think competitiveness of the market  
and lower barriers to entry are important for the long-term health of  
the Web platform, perhaps in some cases more so than slightly better  
basic technologies. So I think the picture is somewhat more complex  
than you paint it.


>> 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?
>
> If they're not enumerable *and* they are based on a de-facto  
> standard, sure.

Sounds good to me.

>
>>> 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.
>
> You did, here:
>>
>
>
> http://old.nabble.com/Re%3A-Another-de-facto-insecurity-we-need-to-fix-in-ES5-p24085298.html
>
> Ok, it was last July, and you allowed how it was too late then for  
> ES5, but the implication was that we ought to have spec'ed such  
> things already. And I might agree, if only there weren't more  
> pressing priorities, and the problem of scarcity causing us to defer  
> a great many work items to after ES5.

My message was pretty clearly about what to do in the future, not  
recriminations about the past. My bottom line from that message still  
stands:

"Personally, I think leaving "distasteful" but cross-browser features   
like this out of the spec in the hopes that they will wither away from  
neglect is a poor approach. If browsers feel pressured to implement  
such extensions for Web compatibility then we are not doing anyone any  
favors by leaving them in the domain of mutual reverse-engineering. I  
would prefer to see such features explicitly specified (with suitable  
restrictions) or explicitly forbidden, and perhaps explicitly  
deprecate them with the plan for further limits or outright removal in  
future versions of the spec."

I think it is uncharitable to characterize this opinion as calling for  
delay.

>
> Hindsight is wonderful, but even if we fallible TC39'ers had managed  
> to use our time better over the last few years, I can think of many  
> more important things to do than spec de-facto __proto__ (the topic  
> of the thread you replied to). At least with ES5 the needs for  
> __proto__ apart from the evil case of mutating an existing object's  
> [[Prototype]] are well-served by standard APIs like Object.create  
> and Object.getPrototypeOf. Spec'ing those instead of __proto__ was a  
> trade-off that I can defend.
>
> I have an easier time defending against our not spending time on  
> Date.parse legacy (rather than ISO-8601) or the HTML string helpers!

I don't think it's as much of a zero-sum game as you are implying.  
Individuals and companies spend effort according to their own  
priorities and skillset. I think we can find a good balance of moving  
the Web forward, and of embracing and taming the legacy.

>
>>>> 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?
>
> We're going to survey and see what can be done. Help welcome.

I'll see if I can find any information in our bug tracker.

>
>>> 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.
>
> We could just underspecify the core language but that is suboptimal,  
> to put it mildly. The other extreme is to bring Global and  
> GlobalProxy types or similar abstraction into ECMA-262. Is there a  
> middle way?

I discussed this briefly over lunch with some TC-39 folks during the  
W3C / TC39 face-to-face recently. One idea was to remove the notion of  
global object as a reified object from ECMAScript entirely - then it  
can be specified completely at the Web standards level in terms of  
relations

It's not clear to me whether this is really doable.

>
>
>>> 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?
>
> Indirect eval is global eval in ES5. But which global? This is a  
> weakness in ES1-5. The interpretation that I favor, which Mozilla at  
> least implements, uses the global in which the indirect eval  
> function was defined (eval is a global function).

Our behavior (as far as I can tell):

otherWindow.eval("...") evaluates with otherWindow as the global object.
randomObject.eval("...") throws
otherWindow.copyOfEvalFromYetAnotherWindow("...") throws

In other words, eval's this value must be the same as the global  
object that defined it, else we throw. In the case where there is a  
match, we evaluate in the global scope of the provided "this" object.  
(Unqualified eval is treated essentially like an operator and does the  
ES5-compliant thing).

>
>
>>> 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()
>
> True, this is a messy issue. Browser JS implementations treat -->  
> differently, as the wiki notes. Possibly this has to go in the core,  
> although again it seems fruitless to require for siloed embeddings  
> that have no commerce with web JS.

My personal tentative sense is that having a consistent lexical  
grammar (and having that fully specified in the core spec) outweighs  
the savings of effort for non-Web-hosted implementations. "<!--"  
itself seems to have consistent behavior. For "-->" there are  
differences and quirks. I think the SpiderMonkey behavior for "-->"  
seems fine and not overly complex. Really this is not much more  
complicated than "//" comments.

>
>>> 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.
>
> Mark, please speak up. I believe TC39 members including Mark and me  
> are concerned about both unflagged conflicts *and* over- 
> specification of legacy stuff we don't think should be formalized if  
> it can be deprecated effectively.

This wiki is all about stuff that's widely implemented, and not about  
the contents of specs as such. So it's not a very helpful guide to  
finding instances of

>
>
>>> 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.
>
> See your mail from July cited above.

My intent with my email was to try to nudge the priorities going  
forward. Specifically I'd like TC-39 lean somewhat more towards the  
spec taking a clear stance on legacy hacks (with possible clear  
stances including forbidding or deprecating them). I suppose you could  
take that as an objection to what had already been done, but I tried  
to be clear that my goal was providing input for future work.

>
>
>> 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.
>
> True. The difference in emphasis may be slight, but it could cause  
> major rear-looking standardization. Anyway, as I wrote to Anne --  
> anyone crossing my bright line of death must do the work (good luck  
> with Date.parse) and then persuade me to spend scarce time reviewing  
> it. I'm not an outlier in resisting such quixotic efforts.

What is your bright line?

>
>
>>> 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.
>
> I don't think so. Clearly no one wants to endorse "blind over- 
> spefication" but I've heard either "let's specify legacy crap  
> feature X fully, it's easy" when it's neither easy nor necessary to  
> over-specify. I've also heard "we will specify all effects other  
> than those dominated by hardware issues". Evidence:
>
> http://lists.w3.org/Archives/Public/public-html/2009Oct/0365.html  
> (Anne on document.all)
> http://lists.w3.org/Archives/Public/public-html/2009Oct/0368.html  
> (my reply to Anne)
> http://lists.w3.org/Archives/Public/public-html/2009Oct/0396.html  
> (Hixie, same thread)
>
> Hixie and I exchanged a few more messages on that "typeof  
> document.all" thread, but I don't think we came to much of an  
> understanding. I owe him some data on cross-browser interop-hazard  
> results to do with memory management. But the general issue of  
> specifying too much legacy is still unresolved, AFAICT.

I do think there is a real difference of views expressed on some of  
those threads, on the tradeoffs related to specifying legacy features  
in detail. But it didn't seem to me that the wiki page called for a  
spirited debate on that topic. It's pretty clear to me that just  
documenting this information is unmitigated goodness, even if some of  
it may never end up in a spec.

That being said, I greatly appreciate your point-by-point comments on  
the specific items listed there. Hopefully we can turn some of those  
into a plan of action. That seems like the most useful thing we can do  
with this wiki page.

Regards,
Maciej