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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
