> FirefoxOS CSP (as a real world example) will absolutely forbid you from
including inline <script>
IMO, this means 'no taco'.
Seems to me this is downside of trying to use <script> here.
On Fri, Apr 12, 2013 at 4:07 PM, Rick Waldron <waldron.rick@gmail.com>wrote:
>
>
>
> 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<
>>>
>>
>>
>