> Why don't we use <script> as the mechanism to import a component?
One of the primary advancements of Custom Elements spec lies in the ability
to combine HTML (templates), scoped CSS, and JavaScript into
encapsulations. General HTML markup is an ideal vehicle.
Specific syntaxes are still under debate, but this is the kind of thing we
do using the polyfills:
<element name='x-bundle-of-awesome'>
<template>
<style>
/* scoped to this element */
</style>
<!-- Shadow DOM markup -->
</template>
<script>
// this === <element>
this.register({ /* controller prototype */});
</script>
</element>
On Wed, Apr 3, 2013 at 12:37 AM, Simon Pieters <simonp@opera.com> wrote:
> On Thu, 28 Mar 2013 20:27:11 +0100, Anne van Kesteren <annevk@annevk.nl>
> wrote:
>
> On Tue, Mar 26, 2013 at 3:59 PM, Dimitri Glazkov <dglazkov@google.com>
>> wrote:
>>
>>> After all resources are loaded and processed, we'll need to process
>>> <element> instances, in reverse order of loading. Processing means:
>>>
>>> 1) Registering a custom element, specified by this <element>. This
>>> will involve running its children <script> elements with some special
>>> rules.
>>> 2) Running element upgrade:
>>> https://dvcs.w3.org/hg/**webcomponents/raw-file/tip/**
>>> spec/custom/index.html#dfn-**element-upgrade<https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-element-upgrade>
>>>
>>> As for the fetching security model, I have a bug for this:
>>> https://www.w3.org/Bugs/**Public/show_bug.cgi?id=21226<https://www.w3.org/Bugs/Public/show_bug.cgi?id=21226>.
>>> Please guide me,
>>> would love your fetch-spec-writing experience :)
>>>
>>> As an additional wrinkle, the webdevs really want this:
>>> https://www.w3.org/Bugs/**Public/show_bug.cgi?id=21229<https://www.w3.org/Bugs/Public/show_bug.cgi?id=21229>
>>>
>>
>> I guess what mostly strikes me as weird is that we're again
>> introducing cross-origin scripts that execute with your principals.
>> That seems bad.
>>
>
> Why don't we use <script> as the mechanism to import a component?
>
> e.g. <script import="url"></script>
>
>
> Assuming we don't find anything better, lets make it clear
>> (monkeypatch for now, I'll create a way) that https -> http fails (we
>> might even want https+EV requires https+EV linking although I'm not
>> sure if you gain much by that). That you really have to trust who you
>> import (suspect the likelyhood of that helping to be close to zero,
>> but who knows).
>>
>>
>>
>
> --
> Simon Pieters
> Opera Software
>
>