On Oct 14, 2010, at 11:15 AM, Brendan Eich wrote:
> On Oct 14, 2010, at 11:09 AM, Brendan Eich wrote:
>
>> Fixing this is possible too, if I can take liberties:
>>
>> <script-if type="application/ecmascript;version=6">
>> // new.js inline-exanded here
>> </script-if else>
>> <script ...>
>> </script>
>> </script-if end>
>
> In case some on es-discuss are not up on HTML and browser implementations of
> it, this would fall back on the <script ...></script> content in old
> browsers, because the </script-if else> looks like an end tag for <script-if
> type=...>. The fallback content is then processed as not in any container (in
> this example). The </script-if end> is a stray end tag, ignored.
>
> New browsers that understood this mock-syntax (I'm not seriously proposing
> it, just sketching) would extend HTML parsing and processing to drop the
> content between the </script-if else> and the </script-if end>.
>
> Again the goal would be
> no-extra-round-trips-with-fallback-for-pre-Harmony-(or-pre-any-version)
> browsers.
I've been talking to Hixie (always stimulating! Also trying to get Maciej's
attention.) My crazy not-quite-HTML sketching aside, the issue Ian and I are
debating, at its best (ignoring any unknown syntax future-proofing proposal),
is something like this:
Should autoconf[1] be the one true versioning approach for JS, syntax or
semantics, as it more-or-less is for DOM API feature testing, etc.?
To be concrete, say you want to use 'let' in your code, and you have a
Narcissus-based translator (maybe this will be a DoctorJS user script, a simple
transform you can customize) to turn let into var and resolve any conflicts
that might arise.
Hixie's suggestion is that you embed a boot-loader script that autoconf-tests:
<script>
var haveLet = false;
try {
eval("let x = 42;");
haveLet = true;
} catch (e) {}
if (haveLet)
loadScript("letbased.js");
else
loadScript("varbased.js");
</script>
(loadScript does document.write of a script tag or whatever is fastest).
This is a mouthful of boilerplate to swallow, but it would work. Perhaps
engines could optimize the eval("let x = 42;") -- eval on a string literal. In
any event, this has the virtue of being backward-compatible, assuming a
suitable loadScript implementation.
My response is to ask "can we not do better?"
Having to write this code, or copy/paste/correct it, is one cost.
Another is the runtime burned on this inline script tag, although that may well
be noise on modern browsers and hardware.
A bigger cost is the generated loadScript runtime. Generated script tags can
hurt. My goal with <altscript> or whatever it would be called is to get this
generated script load back into markup, where it might be speculatively
prefetched.
In principle I don't see what the problem is with extending markup. HTML long
ago deviated from SGML and HTML5 is its own language. Languages are tools, they
should evolve to serve their users.
Maybe there's a good reason why JS version selection with fallback *must*
happen autoconf-style, in JS, with clumy boilerplate, and at the cost of a
generated script load. I do not see it.
/be
[1] http://www.gnu.org/software/autoconf/ (thanks to dherman for this
object-detection analogy/precedent)
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
