New full Unicode for ES6 idea

Brendan Eich brendan at mozilla.com
Sun Feb 19 10:01:48 PST 2012


Axel Rauschmayer wrote:
>>> es-discuss-only idea: could that BRS be made to carry more weight? 
>>> Could it be a switch for all breaking ES.next changes?
>>
>> What do you have in mind? It had better be important. We *just* had 
>> the breakthrough championed by dherman for "One JavaScript". Why make 
>> trouble by adding runtime semantic changes unduly?
>
> Two points:
> - IIRC, attributes such as onclick are not yet solved, the ideas 
> proposed sounded like a BRS, so maybe the two solutions can be combined.

"One JavaScript" means there's nothing to solve for event handlers. 
(Previously, with version opt-in, the solution was Content-Script- Type 
[1], via a HTTP header or <meta http-equiv>).

Could you state the problem with an example?

Perhaps you mean the issue of 'let' at top level in prior scripts (or 
'const'). I think we're all agreed that such bindings (as well as 
'module' bindings at top level) must be visible in event handlers.

> - If we keep in the back of our minds the possibility of using the BRS 
> as ES6 opt-in, while going forward with "One JavaScript" (1JS), both 
> approaches can be tested in the wild. I’m mostly sold on 1JS, but a 
> few doubts remain,

Namely?

We have to test whether extensions such as const and function-in-block 
can be broken, but Apple and Mozilla (at least) are covering that.

We shouldn't over-hedge or try doing two things less well, instead of 
one thing well.

> trying out the BRS "clean cut" solution for Unicode will either allay 
> or confirm those doubts.
Adding a BRS and then starting to hang other hats on it is a design 
mistake. When in doubt, leave it out. This proposal is only for Unicode. 
Of course we can consider other uses if the need truly arises, but we 
should not go looking for them right now.

/be

[1] http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.2.1



More information about the es-discuss mailing list