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

> pollute the window object with $, with ES6 modules around the corner

The $ was just an example, the import could also happily define one or more
modules. This concept allows us to decouple scoping from imports.

Now, the import is only a vehicle, but it advances the state of the art by
also delivering canonical HTML and CSS (instead of requiring JavaScript to
load or encode additional resources). We right away have an efficient
method for draining some of the existing resource management swamp.

>From there I can see paths to supporting opt-in isolation models, either
directly, or by delegating to an agent like DOMWorker.


On Tue, Nov 12, 2013 at 3:21 PM, 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...
>
> 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
> >
>
>