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

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