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

On Tue, May 14, 2013 at 3:11 PM, Dimitri Glazkov <dglazkov@google.com>wrote:

> Note, that this idea does not affect your ability to use <script
> src="...">, only the ability to use defer/async attributes on it.
>
> :DG<
>
>
Oh, thanks for the clarification.  Now I see Scott's post from earlier
specifically calling out the <script src="..."> attribute.



> 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.
> >
>