- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 18 Nov 2013 16:14:39 -0800
- To: Webapps WG <public-webapps@w3.org>
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
Received on Tuesday, 19 November 2013 00:15:38 UTC