- From: Dimitri Glazkov <dglazkov@google.com>
- Date: Tue, 14 May 2013 13:36:22 -0700
- To: public-webapps <public-webapps@w3.org>
- Cc: 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>
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<
Received on Tuesday, 14 May 2013 20:36:49 UTC