Re: [HTML Imports]: what scope to run in

2013-12-04 Thread Jonas Sicking
On Sat, Nov 23, 2013 at 1:51 AM, Jonas Sicking jo...@sicking.cc wrote:
 One thing that we did discuss but that I think we never reached a
 conclusion on was if imported HTML documents need to block module
 tags in the main document. Otherwise there's a risk that named modules
 introduced by the imported HTML document won't be known at the time
 when name resolution happens in the main document. Whether this is a
 problem or not depends on now this name resolution works. I think this
 is still an outstanding question to resolve.

Some further thoughts.

ES6 modules does not have a way for sub-modules to add additional
names. Only top-level module elements can introduce new named
modules.

Following that logic, a HTML-imported document should not be allowed
to introduce additional names. I.e. they can use module elements,
but those module elements should not be able to add new named
modules. Only the top-level HTML document should be able to use
module to introduce names.

If we do that, then that might reduce the race-problems around names
that we were discussing.

/ Jonas



Re: [HTML Imports]: what scope to run in

2013-11-23 Thread Jonas Sicking
On Mon, Nov 18, 2013 at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote:
 At the very least, I would like to see a way to write your
 HTML-importable document as a module. So that it runs in a separate
 global and that the caller can access exported symbols and grab the
 ones that it wants.

We had a brain-storming session about this today and I offered to
write up the conclusions.

Confusion was abound about how various details of ES6 modules work, in
part because not all corner cases have been nailed down yet, or at
least have been nailed down so recently that the message hadn't
reached everyone yet.

Our conclusion was as follows:

We want HTML imports to use the same mechanisms for dealing with name
collisions and module reuse as much as possible.

ES6 currently allows importing modules using both URLs and names. When
a names (rather than URLs) are used, there is a risk of collisions.
Specifically when a document imports two ES6 modules, A and B, both
expect a module named apple to be available, but expect that the
name apple maps to two completely different libraries. To resolve
this ES6 uses a hook which is given enough context as to allow the the
name apple to map to two different modules in A and in B.

We concluded that as long as ES6 only allows referring to module names
added higher up in the original document there is no race condition.
(In hindsight it's unclear to me that this was still a requirement
once we got to the end of the discussion).

We concluded that ES6 needs to use different names when referring to a
module by URL vs. by name. Otherwise it would be impossible for the
HTML prescanner to fire off network requests eagerly which is
important for performance. This does not seem to require changes to
ES6, but it does require consideration when defining how the built-in
resolver hook in browsers should behave.

We should make it a recommendation that HTML pages use module
elements rather than script elements. That way they won't
unnecessarily inject global variables into the loaded page's global
scope.

This still means that named modules in the included HTML will inject
names into the module system map (not sure if I'm getting the name
correctly here?). So this could collide with other names in other
imported HTML documents. However this isn't really any different from
the fact that element names created by different HTML imports can
collide.

Additionally, these collisions can still be dealt with using the same
ES6-provided hook. At least when the ES6 import syntax is used (though
maybe not when the system module map is accessed through API?).
However we need to make it clear that this hook takes into account
HTML imports and exposes the imported script as a context as
appropriate. (Someone that understands this hook better than me will
have to expand on the details here).

We want to introduce a property on the scope object that the module
elements in the imported document lives in. This property would
provide access to the imported document itself. This way we can get
rid of document.currentScript.ownerDocument hacks. (Does
document.currentScript even work in module?)

It would technically be possible to define that script elements
inside the imported documents also run inside a scope object the same
way that modules do. This way imported documents would be less
likely to pollute the global object of the importing page. This idea
didn't seem very popular though. (I still like it :) ).

One thing that we did discuss but that I think we never reached a
conclusion on was if imported HTML documents need to block module
tags in the main document. Otherwise there's a risk that named modules
introduced by the imported HTML document won't be known at the time
when name resolution happens in the main document. Whether this is a
problem or not depends on now this name resolution works. I think this
is still an outstanding question to resolve.

Ok, someone else please quickly fill in any details that I'm missing
since this stuff was complicated enough that it's plopping out of my
head already. And I'm about to go on vacation which will surely
replace all of this stuff with alcoholic beverages and sandy beaches.

Have a great thanksgiving!

/ Jonas



Re: [HTML Imports]: what scope to run in

2013-11-23 Thread John J Barton
On Sat, Nov 23, 2013 at 1:51 AM, Jonas Sicking jo...@sicking.cc wrote:


 It would technically be possible to define that script elements
 inside the imported documents also run inside a scope object the same
 way that modules do. This way imported documents would be less
 likely to pollute the global object of the importing page. This idea
 didn't seem very popular though. (I still like it :) ).


Running JS in a function scope to avoid implicit global creation is quite
popular, the Immediate Invoked Function Expression (IIFE) pattern. Since
that option is available and since module should be available, we should
not redefine what script means in an import.



 One thing that we did discuss but that I think we never reached a
 conclusion on was if imported HTML documents need to block module
 tags in the main document. Otherwise there's a risk that named modules
 introduced by the imported HTML document won't be known at the time
 when name resolution happens in the main document. Whether this is a
 problem or not depends on now this name resolution works. I think this
 is still an outstanding question to resolve.


If we want HTML imports to be able to define named modules, then the ES
System loader must be able to load that module by name. IMO we cannot allow
named modules to be defined that cannot be loaded by name. Then the problem
you outline cannot happen: if the main document or any other ongoing HTML
Import or ES module loading needs a module it looks it up in the System and
blocks until the module is available.


jjb


Re: [HTML Imports]: what scope to run in

2013-11-20 Thread Brian Di Palma
On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron waldron.r...@gmail.com wrote:



 On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa rn...@apple.com wrote:

 We share the concern Jonas expressed here as I've repeatedly mentioned on
 another threads.

 On Nov 18, 2013, at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote:

 This has several downsides:
 * Libraries can easily collide with each other by trying to insert
 themselves into the global using the same property name.
 * It means that the library is forced to hardcode the property name
 that it's accessed through, rather allowing the page importing the
 library to control this.
 * It makes it harder for the library to expose multiple entry points
 since it multiplies the problems above.
 * It means that the library is more fragile since it doesn't know what
 the global object that it runs in looks like. I.e. it can't depend on
 the global object having or not having any particular properties.


 Or for that matter, prototypes of any builtin type such as Array.

 * Internal functions that the library does not want to expose require
 ugly anonymous-function tricks to create a hidden scope.


 IMO, this is the biggest problem.

 Many platforms, including Node.js and ES6 introduces modules as a way
 to address these problems.


 Indeed.

 At the very least, I would like to see a way to write your
 HTML-importable document as a module. So that it runs in a separate
 global and that the caller can access exported symbols and grab the
 ones that it wants.

 Though I would even be interested in having that be the default way of
 accessing HTML imports.


 Yes!  I support that.

 I don't know exactly what the syntax would be. I could imagine something
 like

 In markup:
 link rel=import href=... id=mylib

 Once imported, in script:
 new $('mylib').import.MyCommentElement;
 $('mylib').import.doStuff(12);

 or

 In markup:
 link rel=import href=... id=mylib import=MyCommentElement doStuff

 Once imported, in script:
 new MyCommentElement;
 doStuff(12);


 How about this?

 In the host document:
 link ref=import href=foo.js import=foo1 foo2
 script
 foo1.bar();
 foo2();
 /script

 In foo.js:
 module foo1 {
 export function bar() {}
 }
 function foo2() {}



 Inline module syntax was removed and will not be included in the ES6 module
 specification. Furthermore, the example you've illustrated here isn't
 entirely valid, but the valid parts are already covered within the scope of
 ES6 modules:

 // in some HTML...
 script
 import {foo1, foo2} from foo;

 foo1();
 foo2();
 /script

 // foo.js
 export function foo1() {}
 export function foo2() {}


 (note that foo2 isn't exported in your example, so would be undefined)

 Rick


I thought if an identifier wasn't exported trying to import it would
result in fast failure (SyntaxError)?



Re: [HTML Imports]: what scope to run in

2013-11-20 Thread Rick Waldron
On Wed, Nov 20, 2013 at 12:38 PM, Brian Di Palma off...@gmail.com wrote:

 On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron waldron.r...@gmail.com
 wrote:
 
 
 
  On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa rn...@apple.com wrote:
 
  We share the concern Jonas expressed here as I've repeatedly mentioned
 on
  another threads.
 
  On Nov 18, 2013, at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  This has several downsides:
  * Libraries can easily collide with each other by trying to insert
  themselves into the global using the same property name.
  * It means that the library is forced to hardcode the property name
  that it's accessed through, rather allowing the page importing the
  library to control this.
  * It makes it harder for the library to expose multiple entry points
  since it multiplies the problems above.
  * It means that the library is more fragile since it doesn't know what
  the global object that it runs in looks like. I.e. it can't depend on
  the global object having or not having any particular properties.
 
 
  Or for that matter, prototypes of any builtin type such as Array.
 
  * Internal functions that the library does not want to expose require
  ugly anonymous-function tricks to create a hidden scope.
 
 
  IMO, this is the biggest problem.
 
  Many platforms, including Node.js and ES6 introduces modules as a way
  to address these problems.
 
 
  Indeed.
 
  At the very least, I would like to see a way to write your
  HTML-importable document as a module. So that it runs in a separate
  global and that the caller can access exported symbols and grab the
  ones that it wants.
 
  Though I would even be interested in having that be the default way of
  accessing HTML imports.
 
 
  Yes!  I support that.
 
  I don't know exactly what the syntax would be. I could imagine something
  like
 
  In markup:
  link rel=import href=... id=mylib
 
  Once imported, in script:
  new $('mylib').import.MyCommentElement;
  $('mylib').import.doStuff(12);
 
  or
 
  In markup:
  link rel=import href=... id=mylib import=MyCommentElement
 doStuff
 
  Once imported, in script:
  new MyCommentElement;
  doStuff(12);
 
 
  How about this?
 
  In the host document:
  link ref=import href=foo.js import=foo1 foo2
  script
  foo1.bar();
  foo2();
  /script
 
  In foo.js:
  module foo1 {
  export function bar() {}
  }
  function foo2() {}
 
 
 
  Inline module syntax was removed and will not be included in the ES6
 module
  specification. Furthermore, the example you've illustrated here isn't
  entirely valid, but the valid parts are already covered within the scope
 of
  ES6 modules:
 
  // in some HTML...
  script
  import {foo1, foo2} from foo;
 
  foo1();
  foo2();
  /script
 
  // foo.js
  export function foo1() {}
  export function foo2() {}
 
 
  (note that foo2 isn't exported in your example, so would be undefined)
 
  Rick
 

 I thought if an identifier wasn't exported trying to import it would
 result in fast failure (SyntaxError)?


Yes, my statement above is incorrect.

Rick


Re: [HTML Imports]: what scope to run in

2013-11-20 Thread Hajime Morrita
I'd frame the problem in a slightly different way.

Seems like almost everyone agrees that we need better way to
modularize JavaScript, and ES6 modules are one of the most promising
way to go. And we also agree (I think) that we need a way to connect
ES6 modules and the browser.

What we don't consent to is what is the best way to do it. One option
is to introduce new primitive like jorendorff's module element.
People are also seeing that HTML imports could be another option. So
the conversation could be about which is better, or whether we need
both or not.

If you just want to namespace the script, HTML Imports might be overkill because

 * An import is HTML and HTML isn't JS developer friendly in some
cases. Think about editor integration for example. Application
developers will prefer .js rather than .html as the container of their
code.
 * Given above, HTML imports introduces an indirection with script
src=... and will be slower than directly loading .js files.
 * HTML imports will work well with module-ish thing and it makes
the spec small as it gets off-loaded module loading responsibility.
This seems good modularization of the feature.

HTML Imports make sense only if you need HTML fragments and/or
stylesheets, but people need modularization regardless they develop
Web Components or plain JS pieces. I think the web standard should
help both cases and module or something similar serves better for
that purpose.

Does this make sense?

--
morrita



On Thu, Nov 21, 2013 at 7:00 AM, Rick Waldron waldron.r...@gmail.com wrote:



 On Wed, Nov 20, 2013 at 12:38 PM, Brian Di Palma off...@gmail.com wrote:

 On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron waldron.r...@gmail.com
 wrote:
 
 
 
  On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa rn...@apple.com wrote:
 
  We share the concern Jonas expressed here as I've repeatedly mentioned
  on
  another threads.
 
  On Nov 18, 2013, at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  This has several downsides:
  * Libraries can easily collide with each other by trying to insert
  themselves into the global using the same property name.
  * It means that the library is forced to hardcode the property name
  that it's accessed through, rather allowing the page importing the
  library to control this.
  * It makes it harder for the library to expose multiple entry points
  since it multiplies the problems above.
  * It means that the library is more fragile since it doesn't know what
  the global object that it runs in looks like. I.e. it can't depend on
  the global object having or not having any particular properties.
 
 
  Or for that matter, prototypes of any builtin type such as Array.
 
  * Internal functions that the library does not want to expose require
  ugly anonymous-function tricks to create a hidden scope.
 
 
  IMO, this is the biggest problem.
 
  Many platforms, including Node.js and ES6 introduces modules as a way
  to address these problems.
 
 
  Indeed.
 
  At the very least, I would like to see a way to write your
  HTML-importable document as a module. So that it runs in a separate
  global and that the caller can access exported symbols and grab the
  ones that it wants.
 
  Though I would even be interested in having that be the default way of
  accessing HTML imports.
 
 
  Yes!  I support that.
 
  I don't know exactly what the syntax would be. I could imagine
  something
  like
 
  In markup:
  link rel=import href=... id=mylib
 
  Once imported, in script:
  new $('mylib').import.MyCommentElement;
  $('mylib').import.doStuff(12);
 
  or
 
  In markup:
  link rel=import href=... id=mylib import=MyCommentElement
  doStuff
 
  Once imported, in script:
  new MyCommentElement;
  doStuff(12);
 
 
  How about this?
 
  In the host document:
  link ref=import href=foo.js import=foo1 foo2
  script
  foo1.bar();
  foo2();
  /script
 
  In foo.js:
  module foo1 {
  export function bar() {}
  }
  function foo2() {}
 
 
 
  Inline module syntax was removed and will not be included in the ES6
  module
  specification. Furthermore, the example you've illustrated here isn't
  entirely valid, but the valid parts are already covered within the scope
  of
  ES6 modules:
 
  // in some HTML...
  script
  import {foo1, foo2} from foo;
 
  foo1();
  foo2();
  /script
 
  // foo.js
  export function foo1() {}
  export function foo2() {}
 
 
  (note that foo2 isn't exported in your example, so would be undefined)
 
  Rick
 

 I thought if an identifier wasn't exported trying to import it would
 result in fast failure (SyntaxError)?


 Yes, my statement above is incorrect.

 Rick






-- 
morrita



Re: [HTML Imports]: what scope to run in

2013-11-20 Thread Ryosuke Niwa
On Nov 21, 2013, at 10:41 AM, Hajime Morrita morr...@google.com wrote:
 Seems like almost everyone agrees that we need better way to
 modularize JavaScript, and ES6 modules are one of the most promising
 way to go. And we also agree (I think) that we need a way to connect
 ES6 modules and the browser.
 
 What we don't consent to is what is the best way to do it. One option
 is to introduce new primitive like jorendorff's module element.
 People are also seeing that HTML imports could be another option. So
 the conversation could be about which is better, or whether we need
 both or not.

This is a nice summary.

 * Given above, HTML imports introduces an indirection with script
 src=... and will be slower than directly loading .js files.

This is not the case when you're defining components/custom elements in the 
imported document
because you want both templates, styles, and inline scripts to define those 
custom elements in one HTML document.

 * HTML imports will work well with module-ish thing and it makes
 the spec small as it gets off-loaded module loading responsibility.
 This seems good modularization of the feature.

But authors have to opt-in to benefit from such modularization mechanisms.

 HTML Imports make sense only if you need HTML fragments and/or
 stylesheets, but people need modularization regardless they develop
 Web Components or plain JS pieces. I think the web standard should
 help both cases and module or something similar serves better for
 that purpose.

I'm fine with saying that link[rel=import] is a simple include and module 
element is the way to include modularized HTML and JS files. That, however, 
raises a question as to whether we really need two very similar mechanism to 
accomplish the same thing.

- R. Niwa




Re: [HTML Imports]: what scope to run in

2013-11-20 Thread John J Barton
On Wed, Nov 20, 2013 at 7:34 PM, Ryosuke Niwa rn...@apple.com wrote:

 On Nov 21, 2013, at 10:41 AM, Hajime Morrita morr...@google.com wrote:
  Seems like almost everyone agrees that we need better way to
  modularize JavaScript, and ES6 modules are one of the most promising
  way to go. And we also agree (I think) that we need a way to connect
  ES6 modules and the browser.
 
  What we don't consent to is what is the best way to do it. One option
  is to introduce new primitive like jorendorff's module element.
  People are also seeing that HTML imports could be another option. So
  the conversation could be about which is better, or whether we need
  both or not.

 This is a nice summary.

  * Given above, HTML imports introduces an indirection with script
  src=... and will be slower than directly loading .js files.

 This is not the case when you're defining components/custom elements in
 the imported document
 because you want both templates, styles, and inline scripts to define
 those custom elements in one HTML document.


And in this model, the 'inline script' can use module, meaning that the
JS is modular and relies on modular JS. In this way the two specification
work together.

Earlier I suggested a way to combine these specifications from the other
direction, inventing a small extension to ES module-loader,
System.component(), where JS drives the load of an HTML import.



  * HTML imports will work well with module-ish thing and it makes
  the spec small as it gets off-loaded module loading responsibility.
  This seems good modularization of the feature.

 But authors have to opt-in to benefit from such modularization mechanisms.


As I argued for modularity support previously, I also think there is a
strong case for non-modular forms as well: early adoption, test cases,
simple pages, purely declarative markup sites, future innovations.
 Enforcing modularization is likely, based on history, to lead to fewer
uses even much less that the amount of opt-in to a less rigid solution.
Just consider JavaScript vs every other solution for Web scripting, or HTML
vs XML.



  HTML Imports make sense only if you need HTML fragments and/or
  stylesheets, but people need modularization regardless they develop
  Web Components or plain JS pieces. I think the web standard should
  help both cases and module or something similar serves better for
  that purpose.

 I'm fine with saying that link[rel=import] is a simple include and module
 element is the way to include modularized HTML and JS files. That, however,
 raises a question as to whether we really need two very similar mechanism
 to accomplish the same thing.


The module element remains a rumor to my knowledge and this rumor has it
as a JS only feature. The rest of the module specification is far along,
but again only JS. The story for HTML is well represented...by the HTML
Import system.

The strength of the HTML Import story is declarative include of a complete
HTML sub-document, something we have never enjoyed as a common technology.
Its weakness in my mind is lack of advanced JS features like modules and
dynamic loading; these I see as great additions to be made by the JS
leaders.

I don't see two similar mechanisms for the same goal, but two cooperating
specifications with different strengths that combine nicely. At least on
paper, we need more empirical work with the combination to be sure.

HTH,
jjb


Re: [HTML Imports]: what scope to run in

2013-11-19 Thread Brian Kardell
On Nov 19, 2013 2:22 AM, Ryosuke Niwa rn...@apple.com wrote:


 On Nov 19, 2013, at 2:10 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:

 On Mon, Nov 18, 2013 at 8:26 PM, Ryosuke Niwa rn...@apple.com wrote:

 We share the concern Jonas expressed here as I've repeatedly mentioned
on another threads.

 On Nov 18, 2013, at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote:

 This has several downsides:
 * Libraries can easily collide with each other by trying to insert
 themselves into the global using the same property name.
 * It means that the library is forced to hardcode the property name
 that it's accessed through, rather allowing the page importing the
 library to control this.
 * It makes it harder for the library to expose multiple entry points
 since it multiplies the problems above.
 * It means that the library is more fragile since it doesn't know what
 the global object that it runs in looks like. I.e. it can't depend on
 the global object having or not having any particular properties.


 Or for that matter, prototypes of any builtin type such as Array.

 * Internal functions that the library does not want to expose require
 ugly anonymous-function tricks to create a hidden scope.


 IMO, this is the biggest problem.

 Many platforms, including Node.js and ES6 introduces modules as a way
 to address these problems.


 Indeed.

 At the very least, I would like to see a way to write your
 HTML-importable document as a module. So that it runs in a separate
 global and that the caller can access exported symbols and grab the
 ones that it wants.

 Though I would even be interested in having that be the default way of
 accessing HTML imports.


 Yes!  I support that.

 I don't know exactly what the syntax would be. I could imagine
something like

 In markup:
 link rel=import href=... id=mylib

 Once imported, in script:
 new $('mylib').import.MyCommentElement;
 $('mylib').import.doStuff(12);

 or

 In markup:
 link rel=import href=... id=mylib import=MyCommentElement
doStuff

 Once imported, in script:
 new MyCommentElement;
 doStuff(12);


 How about this?

 In the host document:
 link ref=import href=foo.js import=foo1 foo2
 script
 foo1.bar();
 foo2();
 /script

 In foo.js:
 module foo1 {
 export function bar() {}
 }
 function foo2() {}


 I think you just invented the module element:
https://github.com/jorendorff/js-loaders/blob/master/rationale.md#examples


 Putting the backward compatibility / fallback behavior concern with
respect to the HTML parsing algorithm aside, the current proposal appears
to only support js files.  Are you proposing to extend it so that it can
also load HTML documents just like link[rel=import] does?


I think james burke purposes something to that effect
https://gist.github.com/jrburke/7455354#comment-949905 (relevant bit is in
reply to me, comment #4 if i understand the question)


Re: [HTML Imports]: what scope to run in

2013-11-19 Thread Erik Arvidsson
There seems to be some idea that HTML imports are supposed to do
everything. The primary use case for HTML imports is a way to import DOM
trees. Since HTML already have ways to embed CSS and script, HTML imports
can act as a container format. But do not let perfect be the enemy of good.
Lets not try to fix the issues of CSS and JS by make HTLM import try to
solve all of these at once.

To answer a few points.

You should be able to use module/script type=module inside an HTML
import. It will do the encapsulation (top level vars are not global
vars). Lets focus on solving this problem by itself. It is orthogonal to
importing HTML.

Different global scope. Modules do not provide a new global scope by
default. Why should script/module inside an HTML import do that? That seems
inconsistent. Also, having different Array/Function/Node etc causes issues
because code often expect the prototype to not be different.


James Burke also brought up the issue related to naming on the import side.
That works well for JS because the name that the importer choses does not
change the interface of the object [*]. However, the name of an element is
one of the most important parts of its interface. What happens when you
have multiple HTLM imports that imports the same custom element but with
different names and then these elements are moved between the documents?
Are we going to rename them to ensure that my x-foo is always an XFoo?



On Tue, Nov 19, 2013 at 5:13 AM, Brian Kardell bkard...@gmail.com wrote:


 On Nov 19, 2013 2:22 AM, Ryosuke Niwa rn...@apple.com wrote:
 
 
  On Nov 19, 2013, at 2:10 PM, Dimitri Glazkov dglaz...@chromium.org
 wrote:
 
  On Mon, Nov 18, 2013 at 8:26 PM, Ryosuke Niwa rn...@apple.com wrote:
 
  We share the concern Jonas expressed here as I've repeatedly mentioned
 on another threads.
 
  On Nov 18, 2013, at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  This has several downsides:
  * Libraries can easily collide with each other by trying to insert
  themselves into the global using the same property name.
  * It means that the library is forced to hardcode the property name
  that it's accessed through, rather allowing the page importing the
  library to control this.
  * It makes it harder for the library to expose multiple entry points
  since it multiplies the problems above.
  * It means that the library is more fragile since it doesn't know what
  the global object that it runs in looks like. I.e. it can't depend on
  the global object having or not having any particular properties.
 
 
  Or for that matter, prototypes of any builtin type such as Array.
 
  * Internal functions that the library does not want to expose require
  ugly anonymous-function tricks to create a hidden scope.
 
 
  IMO, this is the biggest problem.
 
  Many platforms, including Node.js and ES6 introduces modules as a way
  to address these problems.
 
 
  Indeed.
 
  At the very least, I would like to see a way to write your
  HTML-importable document as a module. So that it runs in a separate
  global and that the caller can access exported symbols and grab the
  ones that it wants.
 
  Though I would even be interested in having that be the default way of
  accessing HTML imports.
 
 
  Yes!  I support that.
 
  I don't know exactly what the syntax would be. I could imagine
 something like
 
  In markup:
  link rel=import href=... id=mylib
 
  Once imported, in script:
  new $('mylib').import.MyCommentElement;
  $('mylib').import.doStuff(12);
 
  or
 
  In markup:
  link rel=import href=... id=mylib import=MyCommentElement
 doStuff
 
  Once imported, in script:
  new MyCommentElement;
  doStuff(12);
 
 
  How about this?
 
  In the host document:
  link ref=import href=foo.js import=foo1 foo2
  script
  foo1.bar();
  foo2();
  /script
 
  In foo.js:
  module foo1 {
  export function bar() {}
  }
  function foo2() {}
 
 
  I think you just invented the module element:
 https://github.com/jorendorff/js-loaders/blob/master/rationale.md#examples
 
 
  Putting the backward compatibility / fallback behavior concern with
 respect to the HTML parsing algorithm aside, the current proposal appears
 to only support js files.  Are you proposing to extend it so that it can
 also load HTML documents just like link[rel=import] does?
 

 I think james burke purposes something to that effect
 https://gist.github.com/jrburke/7455354#comment-949905 (relevant bit is
 in reply to me, comment #4 if i understand the question)




-- 
erik


Re: [HTML Imports]: what scope to run in

2013-11-19 Thread Rick Waldron
On Mon, Nov 18, 2013 at 7:14 PM, Jonas Sicking jo...@sicking.cc wrote:

 Hi All,

 Largely independently from the thread that Dimitri just started on the
 sync/async/-ish nature of HTML imports I have a problem with how
 script execution in the imported document works.

 Right now it's defined that any script elements in the imported
 document are run in the scope of the window of the document linking to
 the import. I.e. the global object of the document that links to the
 import is used as global object of the running script.

 This is exactly how script elements have always worked in HTML.

 However this is a pretty terrible way of importing libraries.
 Basically the protocol becomes here is my global, do whatever
 modifications you want to it in order to install yourself.

 This has several downsides:
 * Libraries can easily collide with each other by trying to insert
 themselves into the global using the same property name.
 * It means that the library is forced to hardcode the property name
 that it's accessed through, rather allowing the page importing the
 library to control this.
 * It makes it harder for the library to expose multiple entry points
 since it multiplies the problems above.
 * It means that the library is more fragile since it doesn't know what
 the global object that it runs in looks like. I.e. it can't depend on
 the global object having or not having any particular properties.
 * Internal functions that the library does not want to expose require
 ugly anonymous-function tricks to create a hidden scope.

 Many platforms, including Node.js and ES6 introduces modules as a way
 to address these problems.

 It seems to me that we are repeating the same mistake again with HTML
 imports.

 Note that this is *not* about security. It's simply about making a
 more robust platform for libraries. This seems like a bad idea given
 that HTML imports essentially are libraries.

 At the very least, I would like to see a way to write your
 HTML-importable document as a module. So that it runs in a separate
 global


This isn't how node modules or ES6 modules work. A module designed for use
with node can define properties on the `global` (ie. the object whose bound
identifier is the word global) and this is the same global object making
the require(...) call. ES6 modules are evaluated in the same global scope
from which they are imported.

Rick


Re: [HTML Imports]: what scope to run in

2013-11-19 Thread John J Barton
On Tue, Nov 19, 2013 at 2:07 PM, Rick Waldron waldron.r...@gmail.comwrote:




 On Mon, Nov 18, 2013 at 7:14 PM, Jonas Sicking jo...@sicking.cc wrote:

 Hi All,

 Largely independently from the thread that Dimitri just started on the
 sync/async/-ish nature of HTML imports I have a problem with how
 script execution in the imported document works.

 Right now it's defined that any script elements in the imported
 document are run in the scope of the window of the document linking to
 the import. I.e. the global object of the document that links to the
 import is used as global object of the running script.

 This is exactly how script elements have always worked in HTML.

 However this is a pretty terrible way of importing libraries.
 Basically the protocol becomes here is my global, do whatever
 modifications you want to it in order to install yourself.

 This has several downsides:
 * Libraries can easily collide with each other by trying to insert
 themselves into the global using the same property name.
 * It means that the library is forced to hardcode the property name
 that it's accessed through, rather allowing the page importing the
 library to control this.
 * It makes it harder for the library to expose multiple entry points
 since it multiplies the problems above.
 * It means that the library is more fragile since it doesn't know what
 the global object that it runs in looks like. I.e. it can't depend on
 the global object having or not having any particular properties.
 * Internal functions that the library does not want to expose require
 ugly anonymous-function tricks to create a hidden scope.

 Many platforms, including Node.js and ES6 introduces modules as a way
 to address these problems.

 It seems to me that we are repeating the same mistake again with HTML
 imports.

 Note that this is *not* about security. It's simply about making a
 more robust platform for libraries. This seems like a bad idea given
 that HTML imports essentially are libraries.

 At the very least, I would like to see a way to write your
 HTML-importable document as a module. So that it runs in a separate
 global


 This isn't how node modules or ES6 modules work. A module designed for use
 with node can define properties on the `global` (ie. the object whose bound
 identifier is the word global) and this is the same global object making
 the require(...) call. ES6 modules are evaluated in the same global scope
 from which they are imported.


However ES6 modules do solve the list of downsides in Jonas' list. And ES6
modules create a scope so variables and functions declared in a module but
not exported do not pollute the global object as a side-effect of
declaration.

I think ES6 modules for HTML imports provide a good compromise between
current HTML import design (no modules just packaging) and total
iframe-like encapsulation (many practical and design issues).



 Rick





Re: [HTML Imports]: what scope to run in

2013-11-19 Thread Rick Waldron
On Tue, Nov 19, 2013 at 5:27 PM, John J Barton
johnjbar...@johnjbarton.comwrote:


  (snip)



  This isn't how node modules or ES6 modules work. A module designed for
 use with node can define properties on the `global` (ie. the object whose
 bound identifier is the word global) and this is the same global object
 making the require(...) call. ES6 modules are evaluated in the same global
 scope from which they are imported.


 However ES6 modules do solve the list of downsides in Jonas' list. And ES6
 modules create a scope so variables and functions declared in a module but
 not exported do not pollute the global object as a side-effect of
 declaration.

 I think ES6 modules for HTML imports provide a good compromise between
 current HTML import design (no modules just packaging) and total
 iframe-like encapsulation (many practical and design issues).


Yes, completely agree that they are the best solution—as long as their
capabilities are understood and their use is specified within the bounds of
those capabilities.

Rick


[HTML Imports]: what scope to run in

2013-11-18 Thread Jonas Sicking
Hi All,

Largely independently from the thread that Dimitri just started on the
sync/async/-ish nature of HTML imports I have a problem with how
script execution in the imported document works.

Right now it's defined that any script elements in the imported
document are run in the scope of the window of the document linking to
the import. I.e. the global object of the document that links to the
import is used as global object of the running script.

This is exactly how script elements have always worked in HTML.

However this is a pretty terrible way of importing libraries.
Basically the protocol becomes here is my global, do whatever
modifications you want to it in order to install yourself.

This has several downsides:
* Libraries can easily collide with each other by trying to insert
themselves into the global using the same property name.
* It means that the library is forced to hardcode the property name
that it's accessed through, rather allowing the page importing the
library to control this.
* It makes it harder for the library to expose multiple entry points
since it multiplies the problems above.
* It means that the library is more fragile since it doesn't know what
the global object that it runs in looks like. I.e. it can't depend on
the global object having or not having any particular properties.
* Internal functions that the library does not want to expose require
ugly anonymous-function tricks to create a hidden scope.

Many platforms, including Node.js and ES6 introduces modules as a way
to address these problems.

It seems to me that we are repeating the same mistake again with HTML imports.

Note that this is *not* about security. It's simply about making a
more robust platform for libraries. This seems like a bad idea given
that HTML imports essentially are libraries.

At the very least, I would like to see a way to write your
HTML-importable document as a module. So that it runs in a separate
global and that the caller can access exported symbols and grab the
ones that it wants.

Though I would even be interested in having that be the default way of
accessing HTML imports.

I don't know exactly what the syntax would be. I could imagine something like

In markup:
link rel=import href=... id=mylib

Once imported, in script:
new $('mylib').import.MyCommentElement;
$('mylib').import.doStuff(12);

or

In markup:
link rel=import href=... id=mylib import=MyCommentElement doStuff

Once imported, in script:
new MyCommentElement;
doStuff(12);

/ Jonas



Re: [HTML Imports]: what scope to run in

2013-11-18 Thread Scott Miles
I've made similar comments on various threads, so sorry if you've heard
this song before, but here are some basic comments:

The HTMLImports we've been working with so far is not primarily about JS,
it's about HTML.
There are already various ways to modularize JS, including requirejs, other
libs, and of course, ES6 modules.
Isolation of globals has definite use cases, but it also has costs, and is
more intervention than is required for first-party use cases. It's been
argued (convincingly, from my perspective) that isolation can be
successfully implemented via a separate opt-in mechanism.

There are the principles that guide the design as it is now. You have lots
of interesting ideas there, but it feels like re-scoping the problem into a
declarative form of JS modules. I suggest that keeping HTMLImports as
primitive as possible is a virtue on almost all fronts.

Scott



On Mon, Nov 18, 2013 at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote:

 Hi All,

 Largely independently from the thread that Dimitri just started on the
 sync/async/-ish nature of HTML imports I have a problem with how
 script execution in the imported document works.

 Right now it's defined that any script elements in the imported
 document are run in the scope of the window of the document linking to
 the import. I.e. the global object of the document that links to the
 import is used as global object of the running script.

 This is exactly how script elements have always worked in HTML.

 However this is a pretty terrible way of importing libraries.
 Basically the protocol becomes here is my global, do whatever
 modifications you want to it in order to install yourself.

 This has several downsides:
 * Libraries can easily collide with each other by trying to insert
 themselves into the global using the same property name.
 * It means that the library is forced to hardcode the property name
 that it's accessed through, rather allowing the page importing the
 library to control this.
 * It makes it harder for the library to expose multiple entry points
 since it multiplies the problems above.
 * It means that the library is more fragile since it doesn't know what
 the global object that it runs in looks like. I.e. it can't depend on
 the global object having or not having any particular properties.
 * Internal functions that the library does not want to expose require
 ugly anonymous-function tricks to create a hidden scope.

 Many platforms, including Node.js and ES6 introduces modules as a way
 to address these problems.

 It seems to me that we are repeating the same mistake again with HTML
 imports.

 Note that this is *not* about security. It's simply about making a
 more robust platform for libraries. This seems like a bad idea given
 that HTML imports essentially are libraries.

 At the very least, I would like to see a way to write your
 HTML-importable document as a module. So that it runs in a separate
 global and that the caller can access exported symbols and grab the
 ones that it wants.

 Though I would even be interested in having that be the default way of
 accessing HTML imports.

 I don't know exactly what the syntax would be. I could imagine something
 like

 In markup:
 link rel=import href=... id=mylib

 Once imported, in script:
 new $('mylib').import.MyCommentElement;
 $('mylib').import.doStuff(12);

 or

 In markup:
 link rel=import href=... id=mylib import=MyCommentElement doStuff

 Once imported, in script:
 new MyCommentElement;
 doStuff(12);

 / Jonas




Re: [HTML Imports]: what scope to run in

2013-11-18 Thread Ryosuke Niwa
We share the concern Jonas expressed here as I've repeatedly mentioned on 
another threads.

On Nov 18, 2013, at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote:
 This has several downsides:
 * Libraries can easily collide with each other by trying to insert
 themselves into the global using the same property name.
 * It means that the library is forced to hardcode the property name
 that it's accessed through, rather allowing the page importing the
 library to control this.
 * It makes it harder for the library to expose multiple entry points
 since it multiplies the problems above.
 * It means that the library is more fragile since it doesn't know what
 the global object that it runs in looks like. I.e. it can't depend on
 the global object having or not having any particular properties.

Or for that matter, prototypes of any builtin type such as Array.

 * Internal functions that the library does not want to expose require
 ugly anonymous-function tricks to create a hidden scope.

IMO, this is the biggest problem.

 Many platforms, including Node.js and ES6 introduces modules as a way
 to address these problems.

Indeed.

 At the very least, I would like to see a way to write your
 HTML-importable document as a module. So that it runs in a separate
 global and that the caller can access exported symbols and grab the
 ones that it wants.
 
 Though I would even be interested in having that be the default way of
 accessing HTML imports.

Yes!  I support that.

 I don't know exactly what the syntax would be. I could imagine something like
 
 In markup:
 link rel=import href=... id=mylib
 
 Once imported, in script:
 new $('mylib').import.MyCommentElement;
 $('mylib').import.doStuff(12);
 
 or
 
 In markup:
 link rel=import href=... id=mylib import=MyCommentElement doStuff
 
 Once imported, in script:
 new MyCommentElement;
 doStuff(12);


How about this?

In the host document:
link ref=import href=foo.js import=foo1 foo2
script
foo1.bar();
foo2();
/script

In foo.js:
module foo1 {
export function bar() {}
}
function foo2() {}


On Nov 18, 2013, at 4:52 PM, Scott Miles sjmi...@google.com wrote:
 The HTMLImports we've been working with so far is not primarily about JS, 
 it's about HTML.
 There are already various ways to modularize JS, including requirejs, other 
 libs, and of course, ES6 modules.
 Isolation of globals has definite use cases, but it also has costs, and is 
 more intervention than is required for first-party use cases. It's been 
 argued (convincingly, from my perspective) that isolation can be successfully 
 implemented via a separate opt-in mechanism.

I understand your perspective but has anyone outside Google shared the same 
opinion?  If so, could you give us pointers (URL to a post, etc..)?

 I suggest that keeping HTMLImports as primitive as possible is a virtue on 
 almost all fronts.


Running scripts in the host document while keeping the rest in a separate 
document isn't exactly simple IMO.  If we kept a separate document  window 
object, then HTML imports behave more like an display:none iframe with 
automatic JS value binding.

There is a huge advantage in matching iframe's behavior here.

- R. Niwa



Re: [HTML Imports]: what scope to run in

2013-11-18 Thread Dimitri Glazkov
On Mon, Nov 18, 2013 at 8:26 PM, Ryosuke Niwa rn...@apple.com wrote:

 We share the concern Jonas expressed here as I've repeatedly mentioned on
 another threads.

 On Nov 18, 2013, at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote:

 This has several downsides:
 * Libraries can easily collide with each other by trying to insert
 themselves into the global using the same property name.
 * It means that the library is forced to hardcode the property name
 that it's accessed through, rather allowing the page importing the
 library to control this.
 * It makes it harder for the library to expose multiple entry points
 since it multiplies the problems above.
 * It means that the library is more fragile since it doesn't know what
 the global object that it runs in looks like. I.e. it can't depend on
 the global object having or not having any particular properties.


 Or for that matter, prototypes of any builtin type such as Array.

 * Internal functions that the library does not want to expose require
 ugly anonymous-function tricks to create a hidden scope.


 IMO, this is the biggest problem.

 Many platforms, including Node.js and ES6 introduces modules as a way
 to address these problems.


 Indeed.

 At the very least, I would like to see a way to write your
 HTML-importable document as a module. So that it runs in a separate
 global and that the caller can access exported symbols and grab the
 ones that it wants.

 Though I would even be interested in having that be the default way of
 accessing HTML imports.


 Yes!  I support that.

 I don't know exactly what the syntax would be. I could imagine something
 like

 In markup:
 link rel=import href=... id=mylib

 Once imported, in script:
 new $('mylib').import.MyCommentElement;
 $('mylib').import.doStuff(12);

 or

 In markup:
 link rel=import href=... id=mylib import=MyCommentElement doStuff

 Once imported, in script:
 new MyCommentElement;
 doStuff(12);


 How about this?

 In the host document:
 link ref=import href=foo.js import=foo1 foo2
 script
 foo1.bar();
 foo2();
 /script

 In foo.js:
 module foo1 {
 export function bar() {}
 }
 function foo2() {}


I think you just invented the module element:
https://github.com/jorendorff/js-loaders/blob/master/rationale.md#examples

In fact, the list of concerns that Jonas listed is specifically addressed
by modules. So, my thinking is that why don't we leave imports alone and
let the modules solve these problems? HTML Imports is a higher-layer
vehicle -- it simply allows you to build a dependency tree out of HTML
files. In turn, HTML Imports use modules to apply proper scoping of
scripts. And everybody is happy :)

:DG


Re: [HTML Imports]: what scope to run in

2013-11-18 Thread Jonas Sicking
On Mon, Nov 18, 2013 at 9:10 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
 In fact, the list of concerns that Jonas listed is specifically addressed by
 modules. So, my thinking is that why don't we leave imports alone and let
 the modules solve these problems? HTML Imports is a higher-layer vehicle --
 it simply allows you to build a dependency tree out of HTML files. In turn,
 HTML Imports use modules to apply proper scoping of scripts. And everybody
 is happy :)

Except as the specification is currently written, I don't see a way to
do that. I.e. the only way the imported page can communicate back to
the main page is by interacting with its global.

I definitely agree that we shouldn't re-invent modules. I think we
should take advantage of what ES6 already invents. But currently I
don't see how that's possible.

Feel free to provide an example showing that I'm wrong. I'm happy to
simply rely on ES6 modules if that's somehow possible. I just don't
see how that's possible with the current spec.

/ Jonas



Re: [HTML Imports]: what scope to run in

2013-11-18 Thread Ryosuke Niwa

On Nov 19, 2013, at 2:10 PM, Dimitri Glazkov dglaz...@chromium.org wrote:

 On Mon, Nov 18, 2013 at 8:26 PM, Ryosuke Niwa rn...@apple.com wrote:
 We share the concern Jonas expressed here as I've repeatedly mentioned on 
 another threads.
 
 On Nov 18, 2013, at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote:
 This has several downsides:
 * Libraries can easily collide with each other by trying to insert
 themselves into the global using the same property name.
 * It means that the library is forced to hardcode the property name
 that it's accessed through, rather allowing the page importing the
 library to control this.
 * It makes it harder for the library to expose multiple entry points
 since it multiplies the problems above.
 * It means that the library is more fragile since it doesn't know what
 the global object that it runs in looks like. I.e. it can't depend on
 the global object having or not having any particular properties.
 
 Or for that matter, prototypes of any builtin type such as Array.
 
 * Internal functions that the library does not want to expose require
 ugly anonymous-function tricks to create a hidden scope.
 
 IMO, this is the biggest problem.
 
 Many platforms, including Node.js and ES6 introduces modules as a way
 to address these problems.
 
 Indeed.
 
 At the very least, I would like to see a way to write your
 HTML-importable document as a module. So that it runs in a separate
 global and that the caller can access exported symbols and grab the
 ones that it wants.
 
 Though I would even be interested in having that be the default way of
 accessing HTML imports.
 
 Yes!  I support that.
 
 I don't know exactly what the syntax would be. I could imagine something like
 
 In markup:
 link rel=import href=... id=mylib
 
 Once imported, in script:
 new $('mylib').import.MyCommentElement;
 $('mylib').import.doStuff(12);
 
 or
 
 In markup:
 link rel=import href=... id=mylib import=MyCommentElement doStuff
 
 Once imported, in script:
 new MyCommentElement;
 doStuff(12);
 
 
 How about this?
 
 In the host document:
 link ref=import href=foo.js import=foo1 foo2
 script
 foo1.bar();
 foo2();
 /script
 
 In foo.js:
 module foo1 {
 export function bar() {}
 }
 function foo2() {}
 
 I think you just invented the module element: 
 https://github.com/jorendorff/js-loaders/blob/master/rationale.md#examples

Putting the backward compatibility / fallback behavior concern with respect to 
the HTML parsing algorithm aside, the current proposal appears to only support 
js files.  Are you proposing to extend it so that it can also load HTML 
documents just like link[rel=import] does?

 In fact, the list of concerns that Jonas listed is specifically addressed by 
 modules. So, my thinking is that why don't we leave imports alone and let the 
 modules solve these problems? HTML Imports is a higher-layer vehicle -- it 
 simply allows you to build a dependency tree out of HTML files. In turn, HTML 
 Imports use modules to apply proper scoping of scripts.

How does module work with HTML imports?  As far as I read the spec, the 
imported document can define (and only define) whatever module it wants to 
declare on the global scope of the host document.


On Nov 19, 2013, at 3:53 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Mon, Nov 18, 2013 at 9:10 PM, Dimitri Glazkov dglaz...@chromium.org 
 wrote:
 In fact, the list of concerns that Jonas listed is specifically addressed by
 modules. So, my thinking is that why don't we leave imports alone and let
 the modules solve these problems? HTML Imports is a higher-layer vehicle --
 it simply allows you to build a dependency tree out of HTML files. In turn,
 HTML Imports use modules to apply proper scoping of scripts. And everybody
 is happy :)
 
 Except as the specification is currently written, I don't see a way to
 do that. I.e. the only way the imported page can communicate back to
 the main page is by interacting with its global.


Same here.

- R. Niwa