+1, best solution yet in my opinion. This seems far cleaner than previous
proposals, and basically relies on existing script tag mechanics (even
though they are not exposed currently)
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<
>
Received on Tuesday, 14 May 2013 20:57:14 UTC