Re: [webcomponents]: Declarative Custom Elements Take Umpteen, The Karate Kid Edition

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.