> 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 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 wrote:
> >
> > On Tue, Nov 12, 2013 at 12:45 AM, Ryosuke Niwa 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
On Nov 13, 2013, at 7:21 AM, Brian Di Palma 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 wrote:
>>
>> On Tue, Nov 12, 2013 at 12:45 AM, Ryosuke Niwa 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
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 wrote:
>
> On Tue, Nov 12, 2013 at 12:45 AM, Ryosuke Niwa 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
On Tue, Nov 12, 2013 at 12:45 AM, Ryosuke Niwa 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
>
On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov wrote:
> On Sun, Nov 10, 2013 at 6:49 PM, Arthur Barstow wrote:
> On 11/9/13 3:24 AM, ext Ryosuke Niwa wrote:
> Hi all,
>
> We have been discussing cross-orign use case and declarative syntax of web
> components internally at Apple, and here are our straw man proposal to amend
> the existing Web Components specifications to support it.
>
> *1. Modify HTML Imports to run scripts in the imported document itself*
>
> This allows the importee and the importer to not share the same script
> context, etc…
>
> This could be an option and shouldn’t be the default.
I don’t think we want to add a yet another flag to control the behavior.
> By running scripts in a different context, we are ejecting the primary use
> case of enabling frameworks/libraries to better manage their assets and
> dependencies (aka the Bootstrap use case).
That would force same-origin and cross-origin use cases to have different
behaviors because we can’t run the untrusted script in the host document.
In particular, it’s important for the global (window) object to have a
consistent behavior between untrusted cross-origin and trusted same-origin use
cases.
> Rob Dodson’s article has a nice progression explaining the use case:
> http://robdodson.me/blog/2013/08/20/exploring-html-imports/
I don’t think this blog post contains any argument for either behavior.
> Also, check out newly minted Eric Bidelman's article on imports (especially
> the use cases section at the bottom):
> http://www.html5rocks.com/en/tutorials/webcomponents/imports/
I see the following argument for the current behavior:
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 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.
> Re: Custom Elements LC, this is an issue to handle in HTML Imports
> specification, not related to Custom Elements.
>
>
> *2. Add “importcomponents" content attribute on link element*
>
> It defines the list of custom element tag names to be imported from the
> imported HTML document.
> e.g. will export
> custom elements of tag names "tag-1" and "tag-2" from ~. Any name that didn't
> have a definition in the import document is ignored (i.e. if "tag-2" was not
> defined in ~, it would be skipped but "tag-1" will be still imported).
>
> This mechanism prevents the imported document from defining arbitrary
> components in the host document.
>
> Re: Custom Elements LC, this should be handled in HTML Imports specification.
> HTML Imports can rely on Custom Elements specification. Any additional hooks
> that could be needed to facilitate this feature could be added in Custom
> Elements Level 2 specification.
>
>
> *3. Support "static" (write-once) binding of a HTML template*
>
> e.g.
> Name: {{name}} Email:{{email}}
>