W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2013

[HTML Imports]: what scope to run in

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 18 Nov 2013 16:14:39 -0800
Message-ID: <CA+c2ei_BDWovoA=qxc7q8-dAzin6sf9Yr7yznq5T0Q82ZfTwKA@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:20 UTC