Re: Conflicts between W3C specs and ES5?

On Nov 17, 2009, at 3:25 PM, Maciej Stachowiak wrote:

> On Nov 17, 2009, at 1:16 PM, Brendan Eich wrote:
>
>> 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.

I certainly hope so. Not to pick a fight, but the threat I see, for  
which I've cited links to several messages, is one of clearly stated  
intentions to standardize all observable effects in HTML5 that are not  
dominated by hardware issues (whatever that means).


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

Sorry, I don't buy it.

First, Mozilla may fail (even lose market share) in trying to cull  
legacy crap. We'll try to do this in nightlies and betas but often you  
don't find the bad news until you hit the full user base. As noted, we  
tried a while ago to turn off the HTML String.prototype helper methods  
and had to backpeddle quickly.

Second, my specific point about foo.arguments involved V8. Google in  
doing V8 had an opportunity to use their considerable market power, or  
just plain cash or in-kind emoluments, to get the one (I'm sure there  
are a few more but I heard of only one) site still using foo.arguments  
to change.

Google may not yet have much browser market share but that's not  
always the limiting factor in technology evangelism. For years before  
Firefox, web developers motivated by various ideals, along with  
practical concerns, started pushing for standards, using standards- 
mode doctypes, etc. AOL and other big websites helped this effort.

So it's not only up to browser vendors to use their market power for  
bettering the web, and to be fair to Google, Google has made the web  
better in many ways prior to launching Chrome/V8, so I'm picking on  
them a bit to make a point -- they can take it, I trust :-).


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

Sure, I can't possibly do the big picture justice with a few words,  
and Mozilla is committed (even to its market share detriment) to open  
standards and lower barriers to entry. Of course, lower barriers are  
not unmixed goods, they trade off against other work including better  
new standards that might obsolete some rarely-used, high-barrier/hard- 
to-spec legacy de-facto standards.

But as noted above re: foo.arguments, Google, and web developers, the  
big picture is more complex than you paint too (we probably agree on  
all of this), and (my point) much more complex than the spec- 
everything-above-hardware folks paint.


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

I don't think I'm misreading your message. Recrimination is not the  
issue. The issue is de-facto standard codification, however  
distasteful, vs. a cleaner standard that could supersede the de-facto  
standard. You framed this pretty well with __proto__ as the concrete  
case.


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

Sorry, I didn't mean to say you called for delay. I'm trying to  
analyze effects, not intentions.


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

This is obviously true, the ES5 meta-programming API shows how Allen  
Wirfs-Brock's experience and the de-facto basis (__defineGetter__,  
__proto__, etc.) combined to create a new standard that can supersede  
a de-facto standard. Ecma TC39 was not able by consensus to approve  
the de-facto standards without changes, so here (ES5) we are.

But too much of this and we risk design by committee, incompatible  
second-system syndrome, and other bad outcomes. Too little, and we  
spend all our time on trailing-edge cruft, some of which should be  
deprecated because it is rarely used and in decline.

I don't believe the web standards game is zero-sum. Like Captain Kirk,  
I also don't believe in the no-win scenario ;-). We may be reaching  
agreement so I'll leave it at that.


> I think we can find a good balance of moving the Web forward, and of  
> embracing and taming the legacy.

I know you do. Really appreciate the good intentions, still concerned  
about effects.


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

See http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope for  
a proposal that does remove the formerly-global object as a scope  
chain element.


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

What would |this| bind to in global code? We could make it denote the  
undefined value but only under some opt-in stricter-than-strict mode.  
Doing so would be hostile to code migration, though. The lexical_scope  
proposal leaves |this| in global code bound to the "global object".


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

What is the rationale for throwing in this last case, rather than  
using the explicit base object (otherWindow) as |this|?


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

I forgot to ask: doesn't JavaScript in SVG require a CDATA marked  
section around the inline <script> content, which the XML processor  
handles? The JS engine never sees that marked section.


>>> or in an external script, or (as far as I know) passed to eval()

I hope it won't shock you to learn that

<!--

and

-->

have been observed in the middle of external .js files loaded by  
<script src="foo.js"></script> :-(. Refactoring contagion vector.

So yeah, messy. Nevertheless, ECMA-262 implementations in embedded  
devices with no web contacts may not care to hassle with the horrors  
of these old comment-hiding hacks. Informative Annex? Optional-but- 
normative-if-implemented section?


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

Ok, then we need someone to contribute a spec -- we can link a  
placeholder here:

http://wiki.ecmascript.org/doku.php?id=strawman:strawman


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

Lost text -- please continue.


> What is your bright line?

Don't spec de-facto Date.parse.


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

Yes, the wiki page is fine. Long may it live!


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

Agreed.

/be