- From: Dimitri Glazkov <dglazkov@google.com>
- Date: Tue, 14 May 2013 15:11:32 -0700
- To: Robert Ginda <rginda@chromium.org>
- Cc: public-webapps <public-webapps@w3.org>, Scott Miles <sjmiles@google.com>, Erik Arvidsson <arv@chromium.org>, Rick Waldron <waldron.rick@gmail.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Daniel Buchner <daniel@mozilla.com>, Elliott Sprehn <esprehn@gmail.com>
Note, that this idea does not affect your ability to use <script
src="...">, only the ability to use defer/async attributes on it.
:DG<
On Tue, May 14, 2013 at 2:44 PM, Robert Ginda <rginda@chromium.org> wrote:
> On Tue, May 14, 2013 at 1:36 PM, Dimitri Glazkov <dglazkov@google.com>
> wrote:
>>
>> Dear Web-Appsicles and TC39onites,
>>
>> (see
>> http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/thread.html#msg302
>> for the history on the problem)
>>
>> Just as I was diving back into this, and feeling like I don't know
>> enough karate, I chatted with Elliott (cc'd), who had a pretty neat
>> idea.
>>
>> Today, scripting engines in browsers return the value of the script
>> that was executed the <script> block. This value is then promptly
>> dropped on the floor by respective rendering engine. But what if it
>> wasn't?
>>
>> What if instead, we taught the rendering engine to hold on to the last
>> value, returned by the executed <script> block, and only discarded it
>> at the microtask checkpoint?
>>
>> Then, we could teach <element> to look at that stored value and use it
>> to populate the prototype.
>>
>> Consider this example:
>>
>> <element name="foo-bar">
>> ...
>> <script>
>> ({
>> never: 'gonna',
>> give: function() { return 'you up'; }
>> });
>> </script>
>> </element>
>>
>> When parsing this code, something like this will happen:
>> 1) see end of SCRIPT tag, evaluate script, remember its value.
>> 2) see end of ELEMENT tag, create HTMLElementElement, which then
>> 3) grabs stored value
>> 4) creates a prototype by transferring properties from this value
>> 5) registers a new element with this prototype.
>>
>> This seems pretty nice. And it works with ES6 syntax:
>>
>> <element name="foo-bar">
>> ...
>> <script>
>> class FooBar {
>> ...
>> };
>> </script>
>> </element>
>>
>> Of course, this introduces a few constraints:
>> 1) you can't use <script src="..." async/defer> inside <element>
>> 2) you can't decouple <script> blocks from <element> -- they have to
>> be nested inside.
>>
>>
>> WDYT?
>>
>> :DG<
>>
>
> I'd consider anything that *requires* nested script blocks to be pretty
> distasteful. Hacking on JS-inside-HTML is an unpleasant experience,
> especially for folks with syntax aware editors. My time with emacs
> multiple-major-modes was enough to turn me off to it for good.
>
> If I'm going to write any substantial JS, I want it to be in a file
> dedicated to JS. This trumps any ideals about self contained components for
> me.
>
>
> Rob.
>
Received on Tuesday, 14 May 2013 22:12:01 UTC