On Fri, 23 May 2014, Matthew Robb wrote: > > I think this is a great discussion and it would be cool if it could get > mirrored to the other working groups (specifically esdiscuss).
Assuming you mean this thread, it is. :-) (If you meant the HTML spec discussion regarding needs="" and company, that's more about HTML than scripting specifically, which is why it's happening on the WHATWG list.) > It would be great if WebComponents used the Loader and thus you could > easily import a component into an es6 module and you could build a > component that is entirely an es6 module that simply exports it's > relevent bits. This would require something like <link rel="imports" > type="module"> but I almost. > > I'd love to be able to import css from an es6 module or import a > template etc. Could you elaborate on what it would mean for a module to import a template or style sheet? I'm not super-familiar with ES6 modules yet so I'm not sure exactly how this would manifest syntactically. Abstractly, as far as I can tell, we can imagine the superset of the dependency parts of ES6 modules, HTML imports, and HTML in general as described by a model where some central processor has a list of items, along with a mechanism for adding new items to the list, and each item: - has some means of identification so it can be deduped if it is added to the list multiple times - has the ability to fetch its contents if not already available - has the ability to be executed or applied - has a list of other items that it depends on - has a list of promises that it must wait for before being applied - has a current state, probably one of: idle, downloading, waiting for dependencies, ready, applying/executing, loaded, error - has some sort of execution policy, probably one of: block scripts until run, run asap, run when needed (i.e. when its ability to be executed is invoked); maybe some more esoteric policies like running only once anything that depends on it is about to be run itself - has some sort of download policy, e.g.: download asap, download once the "asap" things are downloaded, download only when needed, download when needed but can be precached if there is free available bandwidth. So for example, a style sheet imported by <link> today would be identified by its URL, fetching its contents would use the "Fetch" specification (e.g. fetching over HTTP), applying it would mean adding it to the style sheet set of the current Document, it wouldn't depend on anything initially but if any @imports were found while it was being parsed then those would probably be dependencies, and it would have the policies of "run asap" and "download asap". (Once we have this model in place, it might make sense to add a feature to HTML to control these policies for each resource in the list; e.g., for <link rel=stylesheet>, an attribute.) Similarly, an ES6 module would presumably map to this as follows: the identifier would be the module name, the ability to fetch the contents would be defined by the Loader (if I understand the spec right), what it depends on would be based on the "import" statements, and it would presumably have the policies of "run asap" and "download asap". A <script src defer> element found during parsing could, in this model, be described as an item that is waiting for the promise that describes the Document being parsed, and it would probably have the policies of "run asap" and "download once the 'asap' things are downloaded". One could also imagine having <img whenneeded ...>, an image that would be represented in this system as an item identified by the HTMLImageElement object, which can be told to download via some method e.g. img.fetch(), and whose policies would be "run when needed", "download when needed but can be precached". A script could then tell the system to add this <img> element / HTMLImageElement object as one of the dependencies for a script it was injecting, so that that script doesn't run until the image is downloaded. (Doing this, assuming the script is then told to run immediately, would be another way of telling the image it was needed. That's one reason to have the dependency system be abstract like this: it lets different parts of the platform participate by just exposing a generic interface, so that Web authors think we designed this all as one coherent whole.) Does all that make sense? Did I miss some feature or behaviour that ES6 modules have that can't be described in the above? What/where would be the best place to define such a system, and how would we hook all the specs together to use it? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
