On Fri, Apr 12, 2013 at 7:09 PM, Scott Miles <sjmiles@google.com> wrote:
> > 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.
>
In your opinion and my opinion it definitely means "no taco"—but only on
platforms with such strict CSP. Keep in mind that my proposal, since it's
just good ol' fashioned script tags behaving the same way since 1995,
allows this remote src for those harsh CSP environments:
<element name="flinger">
<template></template>
<script src="flinger.js"></script>
</element>
Rick
>
>
> 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<
>>>>
>>>
>>>
>>
>