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

On Nov 13, 2013, at 7:21 AM, Brian Di Palma <offler@gmail.com> wrote:

> 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…

Indeed!

> 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().

I think we can support something like import="*" that'll import all "global" symbols defined in the component into your namespace.

>> 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.

I'm not sure.  If you have a funky library that ends up polluting Array's prototype for example, then you don't want that pollution to get into other library you're using on the same page.

The fact each library has its own clean slate to play with is a good thing.

>>> 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.

I know that.  What I'm saying is that it completely defeats the point of using worker.  To quote Maciej:

> Other reasons the worker proposal seems weaker than a separate Window-like global object holding the import document:
> 
> (1) The proposal says:
> 
> Note: No asynchronous guarantees are made for DOMWorker, specifically a busy loop inside the worker may hang the main page completely unlike a regular worker. Developers should assume that a DOMWorker is time sharing the same event loops as the owning document.
> 
> Doesn't this completely defeat any benefit to using a Worker instead of, say, a Window-like global object with its own document?
> 
> (2) Using a worker (which therefore has no source document) makes it awkward to use templates, if you wanted to.
> 
> (3) The custom element binding and setup code still runs in the host document, so this doesn't create a strong security boundary because you'd still need to embed external JS and run it in your own security context to set up the custom element. At best this can protect the component from the embedder, but not vice versa.


- R. Niwa