On Fri, Apr 12, 2013 at 6:56 PM, Scott Miles <sjmiles@google.com> wrote:
> It's possible I missed some key bit, but it seems like (1) separates the
> parts of an <element> which IMO is bad for business. I want an 'element
> taco', with everything in the tortilla (guess I need to have lunch).
>
It doesn't explicitly separate anything, but it does let authors choose
their own organization strategy. You may still make an <element> taco, but
FirefoxOS CSP (as a real world example) will absolutely forbid you from
including inline <script>. Large scale "component" libraries might want to
put all of the JS in modules...
// components.js
module Components {
export class Flinger {
constructor() {}
protoMethod() {}
}
export class Flanger {
constructor() {}
protoMethod() {}
}
}
...
components.html
<element name="flinger">
<template></template>
<script>
import { Flinger } from "Components";
</script>
</element>
<element name="flanger">
<template></template>
<script>
import { Flanger } from "Components";
</script>
</element>
Rick
>
> On Fri, Apr 12, 2013 at 3:52 PM, Dimitri Glazkov <dglazkov@google.com>wrote:
>
>> Good brainstorm! So far I see these ideas:
>>
>> 1) The <element> expects the constructor (prototype?) to be already
>> defined somewhere earlier (Rick's strawman).
>>
>> Pros:
>> * Because of the way parser works, nesting <script> in <element> will
>> Just Work (tm)
>> * Custom element initialization can be anywhere, not tied to the <element>
>>
>> Cons:
>> * Pollutes global namespace
>> * Still need to figure out how to deal with generated constructors
>>
>> 2) Invent a new element specifically for the purpose of defining
>> prototypes.
>>
>> Pros:
>> * No legacy/misunderstanding concerns
>> * Precise purpose, no ambiguity
>>
>> Cons:
>> * Yet another element that runs script. WebAppsSec people (and the web
>> devs) will flog us, roll in chicken feathers and parade us around the
>> village
>>
>> :DG<
>>
>
>