Re: [webcomponents] Proposal for Cross Origin Use Case and Declarative Syntax

I'm not sure I would want jQuery UI to pollute the window object with
$, with ES6 modules around the corner it seems like a step backwards
for imports to start polluting window objects with their libraries...

On Tue, Nov 12, 2013 at 9:01 PM, Elliott Sprehn <esprehn@gmail.com> wrote:
>
> On Tue, Nov 12, 2013 at 12:45 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>
>> [...]
>>
>> Script in the import is executed in the context of the window that
>> contains the importingdocument. So window.document refers to the main page
>> document. This has two useful corollaries:
>>
>> functions defined in an import end up on window.
>> you don't have to do anything crazy like append the import's <script>
>> blocks to the main page. Again, script gets executed.
>>
>> What we’re proposing is to execute the script in the imported document so
>> the only real argument is the point that “functions defined in an imported
>> end up on window” (of the host document).
>>
>> I think that’s a bad thing.  We don’t want imported documents to start
>> polluting global scope without the user explicitly importing them.  e.g.
>> "import X" in Python doesn’t automatically import stuff inside the module
>> into your global scope.  To do that, you explicitly say “import * from X”.
>> Similarly, “using std” is discouraged in C++.
>>
>> I don’t think the argument that this is how external script and stylesheet
>> fly either because the whole point of web components is about improving the
>> modularity and reusability of the Web.
>>
>
> What you're proposing breaks a primary use case of:
>
> <link rel="import" href="//apis.google.com/jquery-ui.html">
>
> Authors don't want to list every single component from jQuery UI in the
> import directive, and they don't want the jQuery UI logic to be in a
> different global object. They want to be able to import jQuery UI and have
> it transitively import jQuery thus providing $ in the window in addition to
> all the widgets and their API. ex. body.appendChild(new
> JQUIPanel()).showPanel().
>
> Note also that using a different global produces craziness like Array being
> different or the prototypes of nodes being different. You definitely don't
> want that for the same origin or CORS use case.
>>
>>
>> Fortunately, there is already a boundary that we built that might be just
>> the right fit for this problem: the shadow DOM boundary. A while back, we
>> had lunch with Mozilla security researchers who were interested in
>> harnessing the power of Shadow DOM, and Elliott (cc'd) came up with a pretty
>> nifty proposal called the DOMWorker. I nagged him and he is hopefully going
>> to post it on public-webapps. I am pretty sure that his proposal can address
>> your use case and not cripple the rest of the spec in the process.
>>
>>
>> Assuming you’re referring to
>> https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit,
>> the security model of our proposal is very similar.  All we’re doing is
>> using a HTML-imported document instead of a worker to isolate the
>> cross-origin component.
>>
>> Since we don’t want to run the cross-origin component on a separate
>> thread, I don’t think worker is a good model for cross-origin components.
>
>
> A DOMWorker doesn't run on another thread, see the Note in the introduction.
>
> - E
>

Received on Tuesday, 12 November 2013 23:21:29 UTC