@Rick - when you say "see above", to what are you referring? IMO we arrive
at our intended outcome without introducing <script> scoping or attribute
issues, and at the same time reducing boilerplate, with the following:
<element tagname="x-foo" inherits="SVGElement">
<template>...</template>
<script>
XFooElement.prototype.bar = function(){...}
XFooElement.prototype.readyCallback = function(){...}
</script></element>
</element>
Where am I going wrong here?
On Fri, Apr 12, 2013 at 2:38 PM, Rick Waldron <waldron.rick@gmail.com>wrote:
>
>
> On Friday, April 12, 2013, Scott Miles wrote:
>
>> I think those things are nice but not necessary.
>>
>> In particular, there was a long discussion at one point about how the
>> <template> is inert but a <script> tag has to 'do things'. I found it
>> useful to realize that at the basic level the script only 'does stuff'
>> because it's the only way to express the otherwise inert prototype.
>>
>
> This is exactly what my proposed semantics are based on. (See above)
>
> Rick
>
>
>>
>>
>>
>> On Fri, Apr 12, 2013 at 2:31 PM, Daniel Buchner <daniel@mozilla.com>wrote:
>>
>> @Scott - interesting, but there are valid reasons for having access to
>> the global scope/document:
>>
>> - Components that benefit from top-level delegation
>> - Components that need to analyze their destination environment
>> before codifying their definition
>>
>> Know what I mean?
>>
>> On Fri, Apr 12, 2013 at 2:25 PM, Scott Miles <sjmiles@google.com> wrote:
>>
>> I realize this doesn't fit any existing conceptual model (that I know of)
>> but I think it's worth pointing out that all we really want to do is define
>> a prototype for the element (as opposed to running arbitrary script).
>>
>> Invented pseudo-code (not a proposal, just trying to identify a mental
>> model):
>>
>> <element name="x-foo" extends="<something>">
>> <!-- prototype for markup -->
>> <template>
>> <template>
>> <!-- prototype for instances -->
>> <prototype>
>> readyCallback: function() {
>> },
>> someApi: function() {
>> },
>> someProperty: null
>> </prototype>
>> </element>
>>
>>
>> On Fri, Apr 12, 2013 at 2:13 PM, Erik Arvidsson <arv@chromium.org> wrote:
>>
>> Daniel, what happens in this case?
>>
>> <element name="x-foo">
>> <script>
>> class XFoo extends SVGElement {
>> }
>> </script>
>> </element>
>>
>> This points out 2 short comings with your proposal.
>>
>> 1. This would just replace the global constructor. That might be OK, and
>> we can detect this override to register the class as needed.
>> 2. Prefixing with HTML seems like an anti pattern.
>>
>>
>> On Fri, Apr 12, 2013 at 5:08 PM, Daniel Buchner <daniel@mozilla.com>wrote:
>>
>> @John - what about what I just sent through? It hops over the magical
>> rebinding issue (or so I think), your thoughts?
>>
>>
>> On Fri, Apr 12, 2013 at 2:06 PM, John J Barton <
>> johnjbarton@johnjbarton.com> wrote:
>>
>>
>> Some suggestions:
>>
>> On Fri, Apr 12, 2013 at 12:30 PM, Dimitri Glazkov <dglazkov@google.com>wrote:
>>
>> ... or "How the heck do we initialize custom elements in declarative
>> syntax?"
>>
>> There were good questions raised about the nature of <script> element
>> in the "platonic form" thread. Consider this syntax:
>>
>> <element name="foo-bar">
>>
>>
>> <element constructor="FooBar">
>>
>>
>> <script> ...</script>
>> <template> ... </template>
>> </element>
>>
>> The way <element> should work is like this:
>> a) when </element> is seen
>> b) generate a constructor for this element
>>
>>
>> b) call the nominated ctor, new FooBar(elt).
>>
>> I'm unclear on the practical advantages the instance
>>
>>