New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTML Modules #645

Open
justinfagnani opened this Issue Jun 20, 2017 · 152 comments

Comments

Projects
None yet
@justinfagnani

justinfagnani commented Jun 20, 2017

Now that JavaScript modules are on the verge of widespread browser support, we should think about an HTML module system that plays well with it. HTML Imports doesn't have a mechanism for exporting symbols, nor can they be imported by JavaScript, however its loading behavior is quite compatible with JavaScript modules.

@dglazkov sketched out a proposal for HTML modules here: https://github.com/dglazkov/webcomponents/blob/html-modules/proposals/HTML-Imports-and-ES-Modules.md

The main points are that, using the JavaScript modules plumbing, you can import HTML.

Either in HTML:

<script type="module" url="foo.html">

or JavaScript:

import * as foo from "foo.html";

But within the scope of that sketch there are still several questions about the specifics of exporting symbols from HTML and importing to JavaScript.

@justinfagnani

This comment has been minimized.

Show comment
Hide comment
@justinfagnani

justinfagnani Jun 20, 2017

@TakayoshiKochi made a polyfill (based on the <script type-module> polyfill by @matthewp) that implements one set of choices to the questions, and shows JS and HTML modules working together: https://github.com/TakayoshiKochi/script-type-module/tree/html-module-experiment

justinfagnani commented Jun 20, 2017

@TakayoshiKochi made a polyfill (based on the <script type-module> polyfill by @matthewp) that implements one set of choices to the questions, and shows JS and HTML modules working together: https://github.com/TakayoshiKochi/script-type-module/tree/html-module-experiment

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jun 20, 2017

Contributor

Thanks for starting the discussion, @justinfagnani!

For context for others, I've been involved with @TakayoshiKochi and others trying to firm up what HTML modules means before we present it widely. There's still a variety of possibilities. Here's my high-level overview:


Writing a custom element that authors can include using a single file is a bit tricky. In particular, how do you get your template HTML? (Which is often literally a <template>.)

  • If you want to stay self-contained, and thus friendly to consumers, you're currently forced to inline your HTML into your JavaScript as a template string, then later use innerHTML. This is costly; it requires first parsing it in JavaScript, then later as HTML, and using up extra memory for both representations. It requires all-at-once parsing, instead of streaming, and requires it to be done on the main thread (I think). And it defeats the preload scanner for any subresources.
  • If you want to "use the platform", you'll have to ask your consumers to include the <template> in their index.html, with some well-known ID. Then all of the above disadvantages disappear, but consuming your library is very un-ergonomic.

At a high level, HTML modules wants to solve this problem. I think the case for it being a worthwhile problem would be stronger if we had data on the costs of the HTML-in-a-JS-string solution, but just by inspection it seems pretty bad. Still, I hope we can provide some data.


The next big question then is about developer ergonomics: what should the authoring and consumption experience for web components be?

  • At one extreme, we could just allow importing of inert DocumentFragments via the JS module system. This solves the above problem in a minimal, simple fashion. But, it means you cannot collocate your HTML and JS into a single file. Most modern frameworks seem to aim for a developer experience of collation, from React's JSX, to Vue's .vue files, to Polymer's HTML imports usage, to Angular's HTML-in-a-JS-string approach.
  • At another, we could work to add some opinionated semantics to imported HTML files that make them good as a "container" format for a web component. This is the approach @TakayoshiKochi has gone with, and I think it's a good illustration. It's much less of a primitive, and requires adding new unusual semantics (e.g. executing scripts outside the main document), but that might be OK.

Hope this helps set the stage!

Contributor

domenic commented Jun 20, 2017

Thanks for starting the discussion, @justinfagnani!

For context for others, I've been involved with @TakayoshiKochi and others trying to firm up what HTML modules means before we present it widely. There's still a variety of possibilities. Here's my high-level overview:


Writing a custom element that authors can include using a single file is a bit tricky. In particular, how do you get your template HTML? (Which is often literally a <template>.)

  • If you want to stay self-contained, and thus friendly to consumers, you're currently forced to inline your HTML into your JavaScript as a template string, then later use innerHTML. This is costly; it requires first parsing it in JavaScript, then later as HTML, and using up extra memory for both representations. It requires all-at-once parsing, instead of streaming, and requires it to be done on the main thread (I think). And it defeats the preload scanner for any subresources.
  • If you want to "use the platform", you'll have to ask your consumers to include the <template> in their index.html, with some well-known ID. Then all of the above disadvantages disappear, but consuming your library is very un-ergonomic.

At a high level, HTML modules wants to solve this problem. I think the case for it being a worthwhile problem would be stronger if we had data on the costs of the HTML-in-a-JS-string solution, but just by inspection it seems pretty bad. Still, I hope we can provide some data.


The next big question then is about developer ergonomics: what should the authoring and consumption experience for web components be?

  • At one extreme, we could just allow importing of inert DocumentFragments via the JS module system. This solves the above problem in a minimal, simple fashion. But, it means you cannot collocate your HTML and JS into a single file. Most modern frameworks seem to aim for a developer experience of collation, from React's JSX, to Vue's .vue files, to Polymer's HTML imports usage, to Angular's HTML-in-a-JS-string approach.
  • At another, we could work to add some opinionated semantics to imported HTML files that make them good as a "container" format for a web component. This is the approach @TakayoshiKochi has gone with, and I think it's a good illustration. It's much less of a primitive, and requires adding new unusual semantics (e.g. executing scripts outside the main document), but that might be OK.

Hope this helps set the stage!

@addyosmani

This comment has been minimized.

Show comment
Hide comment
@addyosmani

addyosmani Jun 20, 2017

Thanks for getting a public discussion going, @justinfagnani!

I see HTML Modules as being a good container format for achieving generic subresource dependency specification. They solve a need for platform-level colocated <template>, <style> and <script>/Module in a similar style to what I would get with something like Vue's .vue files or Polymer's existing HTML Imports. I'd love for them to sufficiently export a JS module - I found this to be a shortcoming of HTML Imports when I last used them.

Some questions:

  • What it is about HTML Modules that makes them specific to Web Components? If a third-party decides to just use HTML + CSS + JS in this container format, that should just work too right? I think we should cater for a few different styles of component to work well with HTML Modules.

  • Are HTML Modules primarily a DX convenience for containment? or do we also foresee trying to bake in a performance carrot (e.g preload scanner benefits) to the design?

  • How do we see HTML Modules fitting with respect to the broader Web Packaging efforts?

addyosmani commented Jun 20, 2017

Thanks for getting a public discussion going, @justinfagnani!

I see HTML Modules as being a good container format for achieving generic subresource dependency specification. They solve a need for platform-level colocated <template>, <style> and <script>/Module in a similar style to what I would get with something like Vue's .vue files or Polymer's existing HTML Imports. I'd love for them to sufficiently export a JS module - I found this to be a shortcoming of HTML Imports when I last used them.

Some questions:

  • What it is about HTML Modules that makes them specific to Web Components? If a third-party decides to just use HTML + CSS + JS in this container format, that should just work too right? I think we should cater for a few different styles of component to work well with HTML Modules.

  • Are HTML Modules primarily a DX convenience for containment? or do we also foresee trying to bake in a performance carrot (e.g preload scanner benefits) to the design?

  • How do we see HTML Modules fitting with respect to the broader Web Packaging efforts?

@justinfagnani

This comment has been minimized.

Show comment
Hide comment
@justinfagnani

justinfagnani Jun 20, 2017

I also want to point out that HTML modules would not prescribe how component developers package their libraries, or even prescribe Web Components for that matter.

There are a number of styles that components could be written and/or packaged:

  1. Pure JS, using either template strings, DOM builder libraries, JSX, etc. (no HTML modules)
  2. Logic in JS, template/CSS in HTML: import template from 'template.html'; in the component's module. Maybe event import style from 'styles.css'; is we include CSS modules.
  3. Single-file, like Vue and Polymer: JavaScript, HTML and CSS all in one file.

These styles could all be compatible.

justinfagnani commented Jun 20, 2017

I also want to point out that HTML modules would not prescribe how component developers package their libraries, or even prescribe Web Components for that matter.

There are a number of styles that components could be written and/or packaged:

  1. Pure JS, using either template strings, DOM builder libraries, JSX, etc. (no HTML modules)
  2. Logic in JS, template/CSS in HTML: import template from 'template.html'; in the component's module. Maybe event import style from 'styles.css'; is we include CSS modules.
  3. Single-file, like Vue and Polymer: JavaScript, HTML and CSS all in one file.

These styles could all be compatible.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jun 20, 2017

Contributor

These styles could all be compatible.

That's a good point. Even if we go with an opinionated container format with new capabilities, like @TakayoshiKochi's prototype, it will likely be possible to opt-out of those new capabilities, e.g. by just making your main element a <template> so that everything inside it is inert.

Contributor

domenic commented Jun 20, 2017

These styles could all be compatible.

That's a good point. Even if we go with an opinionated container format with new capabilities, like @TakayoshiKochi's prototype, it will likely be possible to opt-out of those new capabilities, e.g. by just making your main element a <template> so that everything inside it is inert.

@matthewp

This comment has been minimized.

Show comment
Hide comment
@matthewp

matthewp Jun 20, 2017

It looks like @TakayoshiKochi's experiment doesn't create a new document for the imported module. Not sure if this is an intentional omission or not, as the @dglazkov sketch does mention there being a new document like in html imports. Here's an example module for those interested.

In the interest of listing problems and not solutions I would say some things I want (in addition to other things mentioned by people above) are:

  1. I want to be able to export JavaScript modules from an HTML module.
  2. I want to be able to query for elements within the HTML module.
  3. I want to be able to "reach in" to an HTML module some how from the outside and use stuff other than the HTML modules within. But maybe if (1) and (2) are satisfied that would mean that an HTML module could make the other parts (like the <template>) accessible?

matthewp commented Jun 20, 2017

It looks like @TakayoshiKochi's experiment doesn't create a new document for the imported module. Not sure if this is an intentional omission or not, as the @dglazkov sketch does mention there being a new document like in html imports. Here's an example module for those interested.

In the interest of listing problems and not solutions I would say some things I want (in addition to other things mentioned by people above) are:

  1. I want to be able to export JavaScript modules from an HTML module.
  2. I want to be able to query for elements within the HTML module.
  3. I want to be able to "reach in" to an HTML module some how from the outside and use stuff other than the HTML modules within. But maybe if (1) and (2) are satisfied that would mean that an HTML module could make the other parts (like the <template>) accessible?
@TakayoshiKochi

This comment has been minimized.

Show comment
Hide comment
@TakayoshiKochi

TakayoshiKochi Jun 21, 2017

Member

Thanks @justinfagnani for starting this thread! Thanks @domenic for the summary.
I was wondering if this is a good place as @addyosmani mentioned if HTML Modules may not be
specifically for web components. But as it is, this is good starting here in public:)

We're open to any questions / problems for HTML modules.
Feel free to pour your thoughts here.

FYI, here's slide deck I presented in BlinkOn back in February:
https://docs.google.com/presentation/d/1ksnC9Qr3c8RwbDyo1G8ZZSVOEfXpnfQsTHhR5ny9Wk4/edit

Member

TakayoshiKochi commented Jun 21, 2017

Thanks @justinfagnani for starting this thread! Thanks @domenic for the summary.
I was wondering if this is a good place as @addyosmani mentioned if HTML Modules may not be
specifically for web components. But as it is, this is good starting here in public:)

We're open to any questions / problems for HTML modules.
Feel free to pour your thoughts here.

FYI, here's slide deck I presented in BlinkOn back in February:
https://docs.google.com/presentation/d/1ksnC9Qr3c8RwbDyo1G8ZZSVOEfXpnfQsTHhR5ny9Wk4/edit

@TakayoshiKochi

This comment has been minimized.

Show comment
Hide comment
@TakayoshiKochi

TakayoshiKochi Jun 21, 2017

Member

Re @matthewp (#645 (comment))

It looks like @TakayoshiKochi's experiment doesn't create a new document for the imported module.

Yes, it was intentional. Imported HTML is treated as DocumentFragment (as opposed to Document), so we don't have to bother about various semantics to be satisfied, although it yields some weirdness (e.g. why/how can <script> inside be executed?). I'm interested if you prefer Document (other than that was described in Dimitri's doc) to DocumentFragment.

If you're interested in history, here's record of Document vs DocumentFramgent for HTML Imports:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22305

Member

TakayoshiKochi commented Jun 21, 2017

Re @matthewp (#645 (comment))

It looks like @TakayoshiKochi's experiment doesn't create a new document for the imported module.

Yes, it was intentional. Imported HTML is treated as DocumentFragment (as opposed to Document), so we don't have to bother about various semantics to be satisfied, although it yields some weirdness (e.g. why/how can <script> inside be executed?). I'm interested if you prefer Document (other than that was described in Dimitri's doc) to DocumentFragment.

If you're interested in history, here's record of Document vs DocumentFramgent for HTML Imports:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22305

@TakayoshiKochi

This comment has been minimized.

Show comment
Hide comment
@TakayoshiKochi

TakayoshiKochi Jun 21, 2017

Member

We are interested in hearing requirements from framework authors, as HTML modules is not (should not be?) specific to web components definition (= container for custom elements and shadow DOM definition).

I admit that my experimental polyfill was biased towards HTML Imports + web components, and would be a good fit for Polymer or Vue use cases, but I would be more excited if the resulting HTML modules would be usable for more than these frameworks or libraries.

In my blink-dev thread, a developer from Scirra introduced me his very inspiring blog post:
https://www.scirra.com/blog/ashley/34/html-imports-are-the-best-web-component
The post is long, but I recommend reading it from top to bottom - my interpretation is that HTML Imports fit their product development requirement quite well, even though they do not use Shadow DOM and do use only little Custom Elements. That exemplifies the need for something that supports scalable development on web platform, and HTML Imports is one key primitive for it.

Member

TakayoshiKochi commented Jun 21, 2017

We are interested in hearing requirements from framework authors, as HTML modules is not (should not be?) specific to web components definition (= container for custom elements and shadow DOM definition).

I admit that my experimental polyfill was biased towards HTML Imports + web components, and would be a good fit for Polymer or Vue use cases, but I would be more excited if the resulting HTML modules would be usable for more than these frameworks or libraries.

In my blink-dev thread, a developer from Scirra introduced me his very inspiring blog post:
https://www.scirra.com/blog/ashley/34/html-imports-are-the-best-web-component
The post is long, but I recommend reading it from top to bottom - my interpretation is that HTML Imports fit their product development requirement quite well, even though they do not use Shadow DOM and do use only little Custom Elements. That exemplifies the need for something that supports scalable development on web platform, and HTML Imports is one key primitive for it.

@rniwa

This comment has been minimized.

Show comment
Hide comment
@rniwa

rniwa Jun 21, 2017

Contributor

Here's my take on this. In today's world, developers are putting HTML inside their JS, not JS inside their HTML. The fact that we don't currently preload resources in a string literal, or we end up two string representations of HTML if you used string literal to include HTML in a JS file is a pure implementation detail. There is nothing preventing us from implementing an optimization if there was a well known symbol which was used to tag a HTML in a JS.

Furthermore, for various performance reasons, we really need to have a mechanism to define an in-file ES6 module; a mechanism which allows multiple modules to be defined within a single JS file. Once we have that, then it's very natural to define three modules: one with HTML, one with CSS, and one with JS in a single JS file.

So I'm not all convinced that we need to put JS into HTML as done in the HTML import. In fact, we'd likely oppose to such an approach on the basis that popular JS frameworks such as React have gone to the completely other direction of embedding HTML inside JS.

Contributor

rniwa commented Jun 21, 2017

Here's my take on this. In today's world, developers are putting HTML inside their JS, not JS inside their HTML. The fact that we don't currently preload resources in a string literal, or we end up two string representations of HTML if you used string literal to include HTML in a JS file is a pure implementation detail. There is nothing preventing us from implementing an optimization if there was a well known symbol which was used to tag a HTML in a JS.

Furthermore, for various performance reasons, we really need to have a mechanism to define an in-file ES6 module; a mechanism which allows multiple modules to be defined within a single JS file. Once we have that, then it's very natural to define three modules: one with HTML, one with CSS, and one with JS in a single JS file.

So I'm not all convinced that we need to put JS into HTML as done in the HTML import. In fact, we'd likely oppose to such an approach on the basis that popular JS frameworks such as React have gone to the completely other direction of embedding HTML inside JS.

@matthewp

This comment has been minimized.

Show comment
Hide comment
@matthewp

matthewp Jun 21, 2017

@rniwa I find this opinion confusing given your interest in template parts. Are you not interested in that feature either, now? Or are you saying you'd prefer to define your <template> (with parts) as a string literal in JS rather than in HTML. Why?

matthewp commented Jun 21, 2017

@rniwa I find this opinion confusing given your interest in template parts. Are you not interested in that feature either, now? Or are you saying you'd prefer to define your <template> (with parts) as a string literal in JS rather than in HTML. Why?

@web-padawan

This comment has been minimized.

Show comment
Hide comment
@web-padawan

web-padawan Jun 21, 2017

the basis that popular JS frameworks such as React have gone to the completely other direction of embedding HTML inside JS.

While not being a framework author nor a browser developer here, just an end-user, I'd like to say that, although it is a widely adopted approach, it still requires tooling and you'll not be able to serve vanilla HTML, CSS and JS unprocessed by stuff like Webpack and so on.

I'd also like to remind you that React was initially built with PHP where including HTML was once widely used. But is such a mixing really considered as a good practice by PHP developers now?

Furthermore, how shall HTML modules work in browsers with disabled JavaScript? If markup stays in HTML, I can imagine them still working somehow. But what if it is placed in string literals?

web-padawan commented Jun 21, 2017

the basis that popular JS frameworks such as React have gone to the completely other direction of embedding HTML inside JS.

While not being a framework author nor a browser developer here, just an end-user, I'd like to say that, although it is a widely adopted approach, it still requires tooling and you'll not be able to serve vanilla HTML, CSS and JS unprocessed by stuff like Webpack and so on.

I'd also like to remind you that React was initially built with PHP where including HTML was once widely used. But is such a mixing really considered as a good practice by PHP developers now?

Furthermore, how shall HTML modules work in browsers with disabled JavaScript? If markup stays in HTML, I can imagine them still working somehow. But what if it is placed in string literals?

@AshleyScirra

This comment has been minimized.

Show comment
Hide comment
@AshleyScirra

AshleyScirra Jun 21, 2017

I wrote this blog post. I'm interested in participating in work for HTML modules, and I think our experience is valuable: we have published a commercial PWA using ~300 HTML imports.

As I touched on in the blog, I quite like the idea of being able to import a HTML file and get a Document, much like XHR for type "document". So this:

import * as doc from "./myimport.html"

would be similar to assigning doc the Document resulting from fetching myimport.html. You can then querySelector etc. on doc and use its DOM content in the JS module. (IMHO, this is far better than pasting chunks of markup in to strings in JS)

Then all you need to do is add a HTML tag that can propagate to further dependencies. I suggested changing

<link rel="import" href="import.html">

to be equivalent to

<script type="module">
import * as doc from "./myimport.html"
</script>

It could equally be <script type="module" src="myimport.html"></script> to do the same. This means further scripts/imports/modules are loaded and run, etc.

I have to say style application from imports is a useful feature for us - see my example of a dialog definition for an example. It's possible a framework could work around this (e.g. applyStylesFrom(doc)), but it seems a shame if the dialog definition example can't work natively.

If HTML modules covered that, I'd guess that largely covers everything we use imports for. In our case they're largely just the architectural scaffolding that brings together all the components of our web app, and as I tried to emphasise in my blog, they excel at that, particularly since it covers all three aspects of a web app (markup, style, script, at least until Google roll back style application 😢).

I am strongly against trying to use script for any markup or style content. I know some frameworks are having success with that approach, and so we shouldn't do anything that makes that harder. But if you have 1000 lines of markup, surely nobody wants to paste that in to a script as a giant string? I strongly believe that there should at least be the provision for leaving markup in HTML files, and not orient the spec around doing what one framework does today. Remember frameworks come and go over the years. In our case, our PWA is notable for not using VDOM, has almost no use of markup-in-script, uses plain markup (no Angular-style directives), no templating (like {{this}} in markup), and no two-way data binding. I don't think any other framework on the web today takes this approach, but I believe our PWA proves that you can still build scalable, complex web apps that way. I do worry that people have framework-blindness where they think things should be done like the frameworks do, rather than thinking in terms of providing general-purpose capabilities that frameworks of different designs and approaches can make use of, even in the future when everything likely changes.

Anyway, here's a couple of extra ideas that may be useful to extend the utility of HTML modules as I described them. Perhaps it'd be useful to add a selector to pick out specific elements, e.g.:

import "#elem" as elem from "./myimport.html"

Now elem is the DOM element returned by matching the selector #elem on myimport.html. Not sure how to handle multiple results (e.g. using ".myclass" as a selector) - maybe import ".myclass" as [resultsArray] from ".myimport.html"?

Finally I don't know if it makes sense to export from a HTML module, but perhaps you could have something like:

import myElem from "./myimport.html"

where myimport.html has a special tag like

<export name="myElem">
    <div>This div is an exported element!</div>
</export>

Perhaps that could also be reconfigured to re-export a JS module that the HTML module imports, e.g:

<export name="submodule">
    <script type="module" src="a.js"></script>
</export>

...then allowing import submodule from "./myimport.html", which propagates the exports from a.js through the HTML import and in to another JS module. I feel like I'm shooting in the dark there though!

AshleyScirra commented Jun 21, 2017

I wrote this blog post. I'm interested in participating in work for HTML modules, and I think our experience is valuable: we have published a commercial PWA using ~300 HTML imports.

As I touched on in the blog, I quite like the idea of being able to import a HTML file and get a Document, much like XHR for type "document". So this:

import * as doc from "./myimport.html"

would be similar to assigning doc the Document resulting from fetching myimport.html. You can then querySelector etc. on doc and use its DOM content in the JS module. (IMHO, this is far better than pasting chunks of markup in to strings in JS)

Then all you need to do is add a HTML tag that can propagate to further dependencies. I suggested changing

<link rel="import" href="import.html">

to be equivalent to

<script type="module">
import * as doc from "./myimport.html"
</script>

It could equally be <script type="module" src="myimport.html"></script> to do the same. This means further scripts/imports/modules are loaded and run, etc.

I have to say style application from imports is a useful feature for us - see my example of a dialog definition for an example. It's possible a framework could work around this (e.g. applyStylesFrom(doc)), but it seems a shame if the dialog definition example can't work natively.

If HTML modules covered that, I'd guess that largely covers everything we use imports for. In our case they're largely just the architectural scaffolding that brings together all the components of our web app, and as I tried to emphasise in my blog, they excel at that, particularly since it covers all three aspects of a web app (markup, style, script, at least until Google roll back style application 😢).

I am strongly against trying to use script for any markup or style content. I know some frameworks are having success with that approach, and so we shouldn't do anything that makes that harder. But if you have 1000 lines of markup, surely nobody wants to paste that in to a script as a giant string? I strongly believe that there should at least be the provision for leaving markup in HTML files, and not orient the spec around doing what one framework does today. Remember frameworks come and go over the years. In our case, our PWA is notable for not using VDOM, has almost no use of markup-in-script, uses plain markup (no Angular-style directives), no templating (like {{this}} in markup), and no two-way data binding. I don't think any other framework on the web today takes this approach, but I believe our PWA proves that you can still build scalable, complex web apps that way. I do worry that people have framework-blindness where they think things should be done like the frameworks do, rather than thinking in terms of providing general-purpose capabilities that frameworks of different designs and approaches can make use of, even in the future when everything likely changes.

Anyway, here's a couple of extra ideas that may be useful to extend the utility of HTML modules as I described them. Perhaps it'd be useful to add a selector to pick out specific elements, e.g.:

import "#elem" as elem from "./myimport.html"

Now elem is the DOM element returned by matching the selector #elem on myimport.html. Not sure how to handle multiple results (e.g. using ".myclass" as a selector) - maybe import ".myclass" as [resultsArray] from ".myimport.html"?

Finally I don't know if it makes sense to export from a HTML module, but perhaps you could have something like:

import myElem from "./myimport.html"

where myimport.html has a special tag like

<export name="myElem">
    <div>This div is an exported element!</div>
</export>

Perhaps that could also be reconfigured to re-export a JS module that the HTML module imports, e.g:

<export name="submodule">
    <script type="module" src="a.js"></script>
</export>

...then allowing import submodule from "./myimport.html", which propagates the exports from a.js through the HTML import and in to another JS module. I feel like I'm shooting in the dark there though!

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jun 21, 2017

Contributor

Furthermore, how shall HTML modules work in browsers with disabled JavaScript? If markup stays in HTML, I can imagine them still working somehow. But what if it is placed in string literals?

I can answer that, at least: they won't. HTML modules are part of the module system, which is entirely dependent on JavaScript.

Even HTML imports never worked in browsers without JavaScript. (The document would be "imported", but useless, since you need script to access imported documents.)

Contributor

domenic commented Jun 21, 2017

Furthermore, how shall HTML modules work in browsers with disabled JavaScript? If markup stays in HTML, I can imagine them still working somehow. But what if it is placed in string literals?

I can answer that, at least: they won't. HTML modules are part of the module system, which is entirely dependent on JavaScript.

Even HTML imports never worked in browsers without JavaScript. (The document would be "imported", but useless, since you need script to access imported documents.)

@justinfagnani

This comment has been minimized.

Show comment
Hide comment
@justinfagnani

justinfagnani Jun 21, 2017

Even HTML imports never worked in browsers without JavaScript. (The document would be "imported", but useless, since you need script to access imported documents.)

Depending on future developments of course. Declarative custom elements (which we'll talk about at TPAC) presumably wouldn't need script enabled.

justinfagnani commented Jun 21, 2017

Even HTML imports never worked in browsers without JavaScript. (The document would be "imported", but useless, since you need script to access imported documents.)

Depending on future developments of course. Declarative custom elements (which we'll talk about at TPAC) presumably wouldn't need script enabled.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jun 21, 2017

Contributor

Declarative custom elements (which we'll talk about at TPAC) presumably wouldn't need script enabled.

Uh... let's just say I disagree with you very strongly on that, and we can leave that discussion for another time, instead of derailing the thread.

Contributor

domenic commented Jun 21, 2017

Declarative custom elements (which we'll talk about at TPAC) presumably wouldn't need script enabled.

Uh... let's just say I disagree with you very strongly on that, and we can leave that discussion for another time, instead of derailing the thread.

@justinfagnani

This comment has been minimized.

Show comment
Hide comment
@justinfagnani

justinfagnani Jun 21, 2017

@rniwa I wouldn't want to encode only what has become most popular today for two reasons:

  1. Because where we are now is largely a consequence of what capabilities the platform has had. JavaScript developed popular user-land module systems and loaders long before HTML Imports, and is now getting widespread native modules before HTML. Given the lack of support HTML Imports has, Polymer has had to carefully weigh it's options for working in browsers without polyfills. If Polymer had decided to support a pure-JS distribution that would have been be a pragmatic choice only and not an indication of what we'd really like to use.

  2. The assertion (developers are putting HTML inside their JS, not JS inside their HTML) might not be so absolute. Polymer and Vue are current examples of libraries that support single-file HTML components with scripts. There would be much more if it were a native capability.

I'm not saying JS shouldn't also gain pre-loading and multi-module support, of course.

justinfagnani commented Jun 21, 2017

@rniwa I wouldn't want to encode only what has become most popular today for two reasons:

  1. Because where we are now is largely a consequence of what capabilities the platform has had. JavaScript developed popular user-land module systems and loaders long before HTML Imports, and is now getting widespread native modules before HTML. Given the lack of support HTML Imports has, Polymer has had to carefully weigh it's options for working in browsers without polyfills. If Polymer had decided to support a pure-JS distribution that would have been be a pragmatic choice only and not an indication of what we'd really like to use.

  2. The assertion (developers are putting HTML inside their JS, not JS inside their HTML) might not be so absolute. Polymer and Vue are current examples of libraries that support single-file HTML components with scripts. There would be much more if it were a native capability.

I'm not saying JS shouldn't also gain pre-loading and multi-module support, of course.

@milieuChris

This comment has been minimized.

Show comment
Hide comment
@milieuChris

milieuChris Jun 21, 2017

milieuChris commented Jun 21, 2017

@AshleyScirra

This comment has been minimized.

Show comment
Hide comment
@AshleyScirra

AshleyScirra Jun 21, 2017

The only way I can imagine HTML modules being useful with script disabled is if they basically inserted their full DOM content at the place they were included. So to use HTML imports as an example, <link rel="import" href="import.html"> would be equivalent to copy-pasting the contents of import.html in place of that tag. I guess it would actually be nice to have a native way to have your header and footer sections defined in one place.

I get that some people are annoyed by the obnoxious things JS does on some pages. But if you're building a web app, it's simply inconceivable to develop it without JS. It would be like writing an Android app with Java disabled - can you still produce a useful app? The web is still an amazing resource for static documents which can work with JS disabled, but on the whole I think modules are aimed very much at the app side of development, where it would naturally pair with JS logic for an app. Still, I don't see any reason to exclude the HTML-only case. Maybe an include attribute, like <script type="module" src="import.html" include> , could specify to just paste in the DOM content there?

AshleyScirra commented Jun 21, 2017

The only way I can imagine HTML modules being useful with script disabled is if they basically inserted their full DOM content at the place they were included. So to use HTML imports as an example, <link rel="import" href="import.html"> would be equivalent to copy-pasting the contents of import.html in place of that tag. I guess it would actually be nice to have a native way to have your header and footer sections defined in one place.

I get that some people are annoyed by the obnoxious things JS does on some pages. But if you're building a web app, it's simply inconceivable to develop it without JS. It would be like writing an Android app with Java disabled - can you still produce a useful app? The web is still an amazing resource for static documents which can work with JS disabled, but on the whole I think modules are aimed very much at the app side of development, where it would naturally pair with JS logic for an app. Still, I don't see any reason to exclude the HTML-only case. Maybe an include attribute, like <script type="module" src="import.html" include> , could specify to just paste in the DOM content there?

@milieuChris

This comment has been minimized.

Show comment
Hide comment
@milieuChris

milieuChris Jun 21, 2017

milieuChris commented Jun 21, 2017

@rniwa

This comment has been minimized.

Show comment
Hide comment
@rniwa

rniwa Jun 22, 2017

Contributor

Perhaps we need to figure out what the declarative syntax for shadow DOM / custom elements will look like before we can figure out what HTML import should look like.

It's hard to talk about packaging a thing without knowing what the thing looks like.

Contributor

rniwa commented Jun 22, 2017

Perhaps we need to figure out what the declarative syntax for shadow DOM / custom elements will look like before we can figure out what HTML import should look like.

It's hard to talk about packaging a thing without knowing what the thing looks like.

@TakayoshiKochi

This comment has been minimized.

Show comment
Hide comment
@TakayoshiKochi

TakayoshiKochi Jun 22, 2017

Member

For including HTML into HTML, probably you can imagine there is a <include src="..."> HTML tag that magically does what server-side include did on the client side. It would be nice to have.
However it is a separate problem or use case from HTML Modules - which wants to load HTML as a resource and do something on it with scripting.

Member

TakayoshiKochi commented Jun 22, 2017

For including HTML into HTML, probably you can imagine there is a <include src="..."> HTML tag that magically does what server-side include did on the client side. It would be nice to have.
However it is a separate problem or use case from HTML Modules - which wants to load HTML as a resource and do something on it with scripting.

@AshleyScirra

This comment has been minimized.

Show comment
Hide comment
@AshleyScirra

AshleyScirra Jun 22, 2017

Yes, I think the include case should be split out in to a separate discussion. Maybe a new issue should be filed for it?

AshleyScirra commented Jun 22, 2017

Yes, I think the include case should be split out in to a separate discussion. Maybe a new issue should be filed for it?

@TakayoshiKochi

This comment has been minimized.

Show comment
Hide comment
@TakayoshiKochi

TakayoshiKochi Jun 23, 2017

Member

@AshleyScirra if you want it to happen, whatwg/html would be more appropriate place to file an issue than here.

@rniwa declarative Shadow DOM / Custom Elements would be nice to have, but we don't have to be blocked on it, because assuming it's all written in HTML and no script then it is just a plain HTML. Although I can imagine that declarative syntax would not be such a simple thing because its semantics would involve hooks into HTML parser and DOM tree construction...

Furthermore, for various performance reasons, we really need to have a mechanism to define an in-file ES6 module; a mechanism which allows multiple modules to be defined within a single JS file. Once we have that, then it's very natural to define three modules: one with HTML, one with CSS, and one with JS in a single JS file.

Is this idea presented or discussed anywhere? This is very interesting and I would like to learn more about it.

So I'm not all convinced that we need to put JS into HTML as done in the HTML import. In fact, we'd likely oppose to such an approach on the basis that popular JS frameworks such as React have gone to the completely other direction of embedding HTML inside JS.

Real-world web development is constrained by actual implementations of browsers available and used today, and React may be the optimal thing to do modular development on the current web platform, but as we are expanding (relaxing?) the constraints of the platform, we don't have to be trapped in the local optima. (that said, I don't say we should ignore React's popularity)

Member

TakayoshiKochi commented Jun 23, 2017

@AshleyScirra if you want it to happen, whatwg/html would be more appropriate place to file an issue than here.

@rniwa declarative Shadow DOM / Custom Elements would be nice to have, but we don't have to be blocked on it, because assuming it's all written in HTML and no script then it is just a plain HTML. Although I can imagine that declarative syntax would not be such a simple thing because its semantics would involve hooks into HTML parser and DOM tree construction...

Furthermore, for various performance reasons, we really need to have a mechanism to define an in-file ES6 module; a mechanism which allows multiple modules to be defined within a single JS file. Once we have that, then it's very natural to define three modules: one with HTML, one with CSS, and one with JS in a single JS file.

Is this idea presented or discussed anywhere? This is very interesting and I would like to learn more about it.

So I'm not all convinced that we need to put JS into HTML as done in the HTML import. In fact, we'd likely oppose to such an approach on the basis that popular JS frameworks such as React have gone to the completely other direction of embedding HTML inside JS.

Real-world web development is constrained by actual implementations of browsers available and used today, and React may be the optimal thing to do modular development on the current web platform, but as we are expanding (relaxing?) the constraints of the platform, we don't have to be trapped in the local optima. (that said, I don't say we should ignore React's popularity)

@addyosmani

This comment has been minimized.

Show comment
Hide comment
@addyosmani

addyosmani Jun 23, 2017

So I'm not all convinced that we need to put JS into HTML as done in the HTML import. In fact, we'd likely oppose to such an approach on the basis that popular JS frameworks such as React have gone to the completely other direction of embedding HTML inside JS.

I would be very curious to hear opinions from some framework authors - e.g @sebmarkbage (React), @developit (Preact), @yyx990803 (Vue) and @IgorMinar (Angular) on the direction of embedding resources like styles and HTML inside JS. I acknowledge this is an increasingly popular pattern, however I'm curious if the availability of HTML Modules where colocated resources (including ES Modules) are a first-class citizen would actually be something they would find useful.

In particular for the final bundles that get generated from their tools/Webpack.

Vue, at least during the dev/iteration workflow appears to have shifted closer to a HTML Imports-type thing while preserving some of the options for authoring in JSX or styles-in-JS if you really want to. It still converts everything to JS during the build cycle.

Furthermore, for various performance reasons, we really need to have a mechanism to define an in-file ES6 module; a mechanism which allows multiple modules to be defined within a single JS file. Once we have that, then it's very natural to define three modules: one with HTML, one with CSS, and one with JS in a single JS file.

Do you see the need for a mechanism offering multiple ES modules in a single JS file being much different to a HTML module being the container enabling that? e.g

bundle.1.html

<script type="module">...</script>
<script type="module">...</script>
<script type="module">...</script>

addyosmani commented Jun 23, 2017

So I'm not all convinced that we need to put JS into HTML as done in the HTML import. In fact, we'd likely oppose to such an approach on the basis that popular JS frameworks such as React have gone to the completely other direction of embedding HTML inside JS.

I would be very curious to hear opinions from some framework authors - e.g @sebmarkbage (React), @developit (Preact), @yyx990803 (Vue) and @IgorMinar (Angular) on the direction of embedding resources like styles and HTML inside JS. I acknowledge this is an increasingly popular pattern, however I'm curious if the availability of HTML Modules where colocated resources (including ES Modules) are a first-class citizen would actually be something they would find useful.

In particular for the final bundles that get generated from their tools/Webpack.

Vue, at least during the dev/iteration workflow appears to have shifted closer to a HTML Imports-type thing while preserving some of the options for authoring in JSX or styles-in-JS if you really want to. It still converts everything to JS during the build cycle.

Furthermore, for various performance reasons, we really need to have a mechanism to define an in-file ES6 module; a mechanism which allows multiple modules to be defined within a single JS file. Once we have that, then it's very natural to define three modules: one with HTML, one with CSS, and one with JS in a single JS file.

Do you see the need for a mechanism offering multiple ES modules in a single JS file being much different to a HTML module being the container enabling that? e.g

bundle.1.html

<script type="module">...</script>
<script type="module">...</script>
<script type="module">...</script>
@treshugart

This comment has been minimized.

Show comment
Hide comment
@treshugart

treshugart Jun 23, 2017

declarative Shadow DOM / Custom Elements would be nice to have

I'd like to emphasise that a lack of declarative shadow DOM is a pretty massive complaint from the community and shouldn't be dismissed as a nice to have.

treshugart commented Jun 23, 2017

declarative Shadow DOM / Custom Elements would be nice to have

I'd like to emphasise that a lack of declarative shadow DOM is a pretty massive complaint from the community and shouldn't be dismissed as a nice to have.

@justinfagnani

This comment has been minimized.

Show comment
Hide comment
@justinfagnani

justinfagnani Jun 23, 2017

I'd like to emphasise that a lack of declarative shadow DOM is a pretty massive complaint from the community and shouldn't be dismissed as a nice to have.

I don't think it's a dismissal at all. In the context of HTML Modules, the question is whether or not declarative custom elements and shadow roots should block moving forward on modules.

justinfagnani commented Jun 23, 2017

I'd like to emphasise that a lack of declarative shadow DOM is a pretty massive complaint from the community and shouldn't be dismissed as a nice to have.

I don't think it's a dismissal at all. In the context of HTML Modules, the question is whether or not declarative custom elements and shadow roots should block moving forward on modules.

@treshugart

This comment has been minimized.

Show comment
Hide comment
@treshugart

treshugart Jun 23, 2017

👍 just making sure it's being heard is all.

treshugart commented Jun 23, 2017

👍 just making sure it's being heard is all.

@sebmarkbage

This comment has been minimized.

Show comment
Hide comment
@sebmarkbage

sebmarkbage Jun 23, 2017

@addyosmani I do think this general architecture is valuable. It can be used to import both somewhat static content but also for loading pieces of a server-rendered page out-of-order and inject dynamically. So, I'm all for it for frameworks that are HTML heavy and centric.

However, for React, and I believe this is a more general trend, we're increasingly looking for ways to avoid passing static, or server responses, as HTML as the serialization format. For these use cases we might use custom byte codes like Glimmer or some other format. There's a lot of value in a richer serialization format that can include more data to pass to JS, cheap branching and conditional logic, immediate access to references to nodes etc. I'm asking myself what value HTML, as the serialization format, offers to a JS library once it's already up and running. I see soft value like familiarity, and concrete value like browser specific caching formats. However, those have to be weighed against other things.

Even if you use what seems to happen is that you end up with two modes in the JS library to deal with nodes created from HTML and nodes created from another mechanism. That adds complexity and code.

sebmarkbage commented Jun 23, 2017

@addyosmani I do think this general architecture is valuable. It can be used to import both somewhat static content but also for loading pieces of a server-rendered page out-of-order and inject dynamically. So, I'm all for it for frameworks that are HTML heavy and centric.

However, for React, and I believe this is a more general trend, we're increasingly looking for ways to avoid passing static, or server responses, as HTML as the serialization format. For these use cases we might use custom byte codes like Glimmer or some other format. There's a lot of value in a richer serialization format that can include more data to pass to JS, cheap branching and conditional logic, immediate access to references to nodes etc. I'm asking myself what value HTML, as the serialization format, offers to a JS library once it's already up and running. I see soft value like familiarity, and concrete value like browser specific caching formats. However, those have to be weighed against other things.

Even if you use what seems to happen is that you end up with two modes in the JS library to deal with nodes created from HTML and nodes created from another mechanism. That adds complexity and code.

@justinfagnani

This comment has been minimized.

Show comment
Hide comment
@justinfagnani

justinfagnani Jun 23, 2017

Can you clarify

you end up with two modes in the JS library to deal with nodes created from HTML and nodes created from another mechanism. That adds complexity and code.

Node in HTML Modules would be standard Nodes in the rest of the DOM, there wouldn't be different types.

justinfagnani commented Jun 23, 2017

Can you clarify

you end up with two modes in the JS library to deal with nodes created from HTML and nodes created from another mechanism. That adds complexity and code.

Node in HTML Modules would be standard Nodes in the rest of the DOM, there wouldn't be different types.

@M-jerez

This comment has been minimized.

Show comment
Hide comment
@M-jerez

M-jerez Jul 31, 2018

This is what i would do:
The template tag already contains html without render or parsing it.

//named html import
<template  href='./my-module.html' id='my-module'></template>
<include  src='my-module' />

//unnamed html import
<include href='./my-module.html' />

Why are we being forced to use javascript to do this? .
If this becomes part of the html standar we would say godbay to rebuild all the pages when a navigation menu is rebuild, sidebar widgets etc.

M-jerez commented Jul 31, 2018

This is what i would do:
The template tag already contains html without render or parsing it.

//named html import
<template  href='./my-module.html' id='my-module'></template>
<include  src='my-module' />

//unnamed html import
<include href='./my-module.html' />

Why are we being forced to use javascript to do this? .
If this becomes part of the html standar we would say godbay to rebuild all the pages when a navigation menu is rebuild, sidebar widgets etc.

@sohrabsaran

This comment has been minimized.

Show comment
Hide comment
@sohrabsaran

sohrabsaran Aug 7, 2018

Hi,
Please do not scrap the html imports idea, it seems very logical and easy to use. Please accelerate its standardization. Please provide information in this thread as to the cdn of the polyfill and a link to a detailed description of how to use the polyfill.

I've had on-and-off contact with web development (so far) starting from 1999, so I am someone who is not too biased by deep experience in React or Angular. Here's what appears logical to me:

  1. The web page is an .html file (html document).
  2. Html forms the base, not javascript. We want things to be as declarative as possible, right?
  3. An html document can import html files that are sub-pages (sub-documents), or html fragments.
    If html fragments, they could be one or more component templates, or a collection of scripts and css files to include etc.
  4. The import link can be given an ID.
  5. A declarative html syntax should exist for the developer to automatically plop in at that location, the cloned content or sub-content of the link specified by its ID. Maybe the tag syntax could be:
<clone linkid="xxxxx" queryselector="yyyyy" >

...where xxxx is the id of the link (or leave this attribute out to select the current html doc/fragment), and:
yyyy is the same string you would pass to document.querySelector().
6. Coming to the questions asked in the opening post in this thread, my vote is that:

import * as foo from "foo.html";

...looks logical, but:

<script type="module" url="foo.html">

...looks illogical and should be supported only as a quirk (if at all), because "an html file is supposed to be far more than just a script". For the second case we already have:

<link rel="import" href="foo.html" id="foo">

..., isn't it?
7. By default functions and variables in the script tag of an html document or in a .js file should have private scope. Same is the case with html tags in an html file. A keyword should exist like 'public' or 'protected' to control the scope/visibility of the function, variable or html tag. If this understanding is not backward compatible, an option similar to the "use strict" option, such as "use default private" should be provided. In html the syntax could be:

<meta defaultscope="private">

sohrabsaran commented Aug 7, 2018

Hi,
Please do not scrap the html imports idea, it seems very logical and easy to use. Please accelerate its standardization. Please provide information in this thread as to the cdn of the polyfill and a link to a detailed description of how to use the polyfill.

I've had on-and-off contact with web development (so far) starting from 1999, so I am someone who is not too biased by deep experience in React or Angular. Here's what appears logical to me:

  1. The web page is an .html file (html document).
  2. Html forms the base, not javascript. We want things to be as declarative as possible, right?
  3. An html document can import html files that are sub-pages (sub-documents), or html fragments.
    If html fragments, they could be one or more component templates, or a collection of scripts and css files to include etc.
  4. The import link can be given an ID.
  5. A declarative html syntax should exist for the developer to automatically plop in at that location, the cloned content or sub-content of the link specified by its ID. Maybe the tag syntax could be:
<clone linkid="xxxxx" queryselector="yyyyy" >

...where xxxx is the id of the link (or leave this attribute out to select the current html doc/fragment), and:
yyyy is the same string you would pass to document.querySelector().
6. Coming to the questions asked in the opening post in this thread, my vote is that:

import * as foo from "foo.html";

...looks logical, but:

<script type="module" url="foo.html">

...looks illogical and should be supported only as a quirk (if at all), because "an html file is supposed to be far more than just a script". For the second case we already have:

<link rel="import" href="foo.html" id="foo">

..., isn't it?
7. By default functions and variables in the script tag of an html document or in a .js file should have private scope. Same is the case with html tags in an html file. A keyword should exist like 'public' or 'protected' to control the scope/visibility of the function, variable or html tag. If this understanding is not backward compatible, an option similar to the "use strict" option, such as "use default private" should be provided. In html the syntax could be:

<meta defaultscope="private">
@AshleyScirra

This comment has been minimized.

Show comment
Hide comment
@AshleyScirra

AshleyScirra Aug 7, 2018

FWIW I've been keeping this repo relatively up-to-date: https://github.com/AshleyScirra/import-as-and-html-modules
It could be used as a starting point for implementing something like HTML modules in a JS library. Note however this isn't a polyfill nor is it in any way official or based on any kind of spec. (I have a separate quick-and-dirty polyfill for HTML imports here: https://github.com/AshleyScirra/html-imports-polyfill)

However as discussed at AshleyScirra/import-as-and-html-modules#2, my latest thinking is just to use ES modules, and bring in markup and style using something similar to importAs. ES modules got there first as "the" module system for web development, and I don't think there's anything to gain by making a parallel one that goes through HTML.

AshleyScirra commented Aug 7, 2018

FWIW I've been keeping this repo relatively up-to-date: https://github.com/AshleyScirra/import-as-and-html-modules
It could be used as a starting point for implementing something like HTML modules in a JS library. Note however this isn't a polyfill nor is it in any way official or based on any kind of spec. (I have a separate quick-and-dirty polyfill for HTML imports here: https://github.com/AshleyScirra/html-imports-polyfill)

However as discussed at AshleyScirra/import-as-and-html-modules#2, my latest thinking is just to use ES modules, and bring in markup and style using something similar to importAs. ES modules got there first as "the" module system for web development, and I don't think there's anything to gain by making a parallel one that goes through HTML.

@twoBirds

This comment has been minimized.

Show comment
Hide comment
@twoBirds

twoBirds Aug 11, 2018

tl;dr:

HTML:

<body js="util.Router">

JS: /util/Router.js

util.Router = class{
   ...
}

// ... if util.Router doesnt exist in the global namespace, load it 
// ... make an instance of that class and put it in the <body> node

Hi everybody,
sorry I am joining in late. Also I am not sure how my approach fits the issue at hand. I have been working on web components and imports since 2004, and have a working web component solution since 2006. I would like to discuss the issue further, though.

My results (and this is just what I am most comfortable with) are as follows:

I want tags like this...

<ul js='tools.MyUlHelperClassName'>

This works if you have a global repository variable "tools" containing the "MyUlHelperClassName" class, much like the user builtin elements in the web components definition: <ul is="....">

or

<tools-myulhelperclassname>

ACE (autonomous custom element) style, does not need global name space, since it can be defined in an IIFE and uses the browser internal element repository.

Since the latter is just a wrapper layer for the first in my system, I will only explain the first here:

The js="..." attribute holds a space-separated list of classnames like e.g.:

<body js="util.Router ...">

My library - and my proposal would be the module loader as well - works like this (a bit simplified):

if there is no global hash object "util":
   let util={}
if "util" doesnt contain a property "Router":          
   load "/util/Router.js" 

// finally - assuming util.Router exists now and is a class
if `<body>` does not have a property "js":    
   body.js = {}
body.js['util.Router'] = new util.Router()
body.js['util.Router'].target = <body>
if body.js['util.Router'] contains an "init" method: 
   body.js['util.Router'].init()       //bootstrapping

Using this approach, any type of additional import technology is unnecessary, since any number of distinct instances can reside in a single DOM node. Also you can have different CORS sources using a domain lookup table for these namespaces, so functionality can be shared
-> e.g. having a self defined input field, but loading the verification functionality from a different source.

All template handling happens inside the instance code. I do not require shadowdom or encapsuled CSS, but can use it if required. I have this since 2006 and happily do recursive on-demand module loading, so during development I dont even need a build.

What do you think about this approach? In my opinion the beauty of it is that it is all based on plain classes, and assumptions on the system are minimal: it only reserves a "js" attribute in the DOM node and also a "js" property being a hash object containing the instances.

Kind regards,
Frankie

PS: here is an example that is a bit more telling, a web component as I do it

info.Header = class extends Tb{

    constructor(){
        super();
        let that = this;
        that.one(
            'init',
            that.init
        );
        that.on(
            'attributeChanged', 
            function(e){ 
                console.log(e); 
            }
        );
    }

    get template(){ return `
        <h1>twoBirds-info</h1>`;
    }

    // methods
    init(){
        let that = this;
        $(that.target)
            .append( $(that.template) );

    }

};
$('<div>').append('<info-header header>'); // define watched attributes TODO refactor

See a small skeleton at work here and the source here. BTW "$" is not jQuery, it my own stuff, but much like it. Also if you inspect the DOM in the skeleton you will find the attribute name is "data-tb" and the property name is "tb" just to avoid conflicts as much as possible.
Lastly: tB ES6 todoMVC

twoBirds commented Aug 11, 2018

tl;dr:

HTML:

<body js="util.Router">

JS: /util/Router.js

util.Router = class{
   ...
}

// ... if util.Router doesnt exist in the global namespace, load it 
// ... make an instance of that class and put it in the <body> node

Hi everybody,
sorry I am joining in late. Also I am not sure how my approach fits the issue at hand. I have been working on web components and imports since 2004, and have a working web component solution since 2006. I would like to discuss the issue further, though.

My results (and this is just what I am most comfortable with) are as follows:

I want tags like this...

<ul js='tools.MyUlHelperClassName'>

This works if you have a global repository variable "tools" containing the "MyUlHelperClassName" class, much like the user builtin elements in the web components definition: <ul is="....">

or

<tools-myulhelperclassname>

ACE (autonomous custom element) style, does not need global name space, since it can be defined in an IIFE and uses the browser internal element repository.

Since the latter is just a wrapper layer for the first in my system, I will only explain the first here:

The js="..." attribute holds a space-separated list of classnames like e.g.:

<body js="util.Router ...">

My library - and my proposal would be the module loader as well - works like this (a bit simplified):

if there is no global hash object "util":
   let util={}
if "util" doesnt contain a property "Router":          
   load "/util/Router.js" 

// finally - assuming util.Router exists now and is a class
if `<body>` does not have a property "js":    
   body.js = {}
body.js['util.Router'] = new util.Router()
body.js['util.Router'].target = <body>
if body.js['util.Router'] contains an "init" method: 
   body.js['util.Router'].init()       //bootstrapping

Using this approach, any type of additional import technology is unnecessary, since any number of distinct instances can reside in a single DOM node. Also you can have different CORS sources using a domain lookup table for these namespaces, so functionality can be shared
-> e.g. having a self defined input field, but loading the verification functionality from a different source.

All template handling happens inside the instance code. I do not require shadowdom or encapsuled CSS, but can use it if required. I have this since 2006 and happily do recursive on-demand module loading, so during development I dont even need a build.

What do you think about this approach? In my opinion the beauty of it is that it is all based on plain classes, and assumptions on the system are minimal: it only reserves a "js" attribute in the DOM node and also a "js" property being a hash object containing the instances.

Kind regards,
Frankie

PS: here is an example that is a bit more telling, a web component as I do it

info.Header = class extends Tb{

    constructor(){
        super();
        let that = this;
        that.one(
            'init',
            that.init
        );
        that.on(
            'attributeChanged', 
            function(e){ 
                console.log(e); 
            }
        );
    }

    get template(){ return `
        <h1>twoBirds-info</h1>`;
    }

    // methods
    init(){
        let that = this;
        $(that.target)
            .append( $(that.template) );

    }

};
$('<div>').append('<info-header header>'); // define watched attributes TODO refactor

See a small skeleton at work here and the source here. BTW "$" is not jQuery, it my own stuff, but much like it. Also if you inspect the DOM in the skeleton you will find the attribute name is "data-tb" and the property name is "tb" just to avoid conflicts as much as possible.
Lastly: tB ES6 todoMVC

@yucer

This comment has been minimized.

Show comment
Hide comment
@yucer

yucer Sep 16, 2018

I am somehow confused by this big thread.

I though this topic was already documented by w3c in October 23th, 1998 and successfully implemented by "Microsoft Internet Explorer" since version 5.5.

I remember I have tested it in 2000 implementing a Datetime selection component (Calendar) with complex logic of JavaScript (named DHTML Behaviours) embedded. It was very easy to reuse in every page.

Are you pretending it never existed or did I mistake the topic?

yucer commented Sep 16, 2018

I am somehow confused by this big thread.

I though this topic was already documented by w3c in October 23th, 1998 and successfully implemented by "Microsoft Internet Explorer" since version 5.5.

I remember I have tested it in 2000 implementing a Datetime selection component (Calendar) with complex logic of JavaScript (named DHTML Behaviours) embedded. It was very easy to reuse in every page.

Are you pretending it never existed or did I mistake the topic?

@dandclark

This comment has been minimized.

Show comment
Hide comment
@dandclark

dandclark Oct 4, 2018

I've been reading through this thread with great interest -- I think that an HTML Imports system redesigned to integrate well with ES6 Modules will be very powerful. I work on the Edge team at Microsoft and have been investigating this subject at length together with several colleagues (@samsebree, @travisleithead, @BoCupp, @arronei). We've put together a document summarizing the issues we've seen called out in this thread and linked discussions, along with proposed solutions that together constitute an HTML Modules system:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/html-modules-proposal.md

Some parts of the proposal will look familiar as they're riffing on and combining ideas found here.

Feedback would be greatly appreciated! Tagging some other implementers on this thread: @domenic @TakayoshiKochi @rniwa @annevk

dandclark commented Oct 4, 2018

I've been reading through this thread with great interest -- I think that an HTML Imports system redesigned to integrate well with ES6 Modules will be very powerful. I work on the Edge team at Microsoft and have been investigating this subject at length together with several colleagues (@samsebree, @travisleithead, @BoCupp, @arronei). We've put together a document summarizing the issues we've seen called out in this thread and linked discussions, along with proposed solutions that together constitute an HTML Modules system:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/html-modules-proposal.md

Some parts of the proposal will look familiar as they're riffing on and combining ideas found here.

Feedback would be greatly appreciated! Tagging some other implementers on this thread: @domenic @TakayoshiKochi @rniwa @annevk

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 5, 2018

Member

Overall that looks good, though to me the contrasting with HTML Imports makes it a bit hard to read. Not having import.meta.document available externally does seem like a problem of sorts though. At least I suspect that'll lead to quite awkward patterns for more complex setups. Did you look into that?

Also, what I'm personally quite interested in is working out all the details of this "new" HTML format and its processing model. How do we tweak the parser, the elements, fetching, etc. to make it all work.

Member

annevk commented Oct 5, 2018

Overall that looks good, though to me the contrasting with HTML Imports makes it a bit hard to read. Not having import.meta.document available externally does seem like a problem of sorts though. At least I suspect that'll lead to quite awkward patterns for more complex setups. Did you look into that?

Also, what I'm personally quite interested in is working out all the details of this "new" HTML format and its processing model. How do we tweak the parser, the elements, fetching, etc. to make it all work.

@AshleyScirra

This comment has been minimized.

Show comment
Hide comment
@AshleyScirra

AshleyScirra Oct 5, 2018

From a web developer point of view, in a production web app like Construct 3, we write scripts solely in separate script files and never use inline scripts. So limiting import.meta.document to inline scripts only essentially makes it useless. To be useful I think it should be always available, and refer only to the most recent or most deeply nested importing document.

I still think that in practice a better architecture would be to simply use script modules as the dependency system, and import static HTML files. This should be straightforward and side-steps problems 3, 4 and 5.

AshleyScirra commented Oct 5, 2018

From a web developer point of view, in a production web app like Construct 3, we write scripts solely in separate script files and never use inline scripts. So limiting import.meta.document to inline scripts only essentially makes it useless. To be useful I think it should be always available, and refer only to the most recent or most deeply nested importing document.

I still think that in practice a better architecture would be to simply use script modules as the dependency system, and import static HTML files. This should be straightforward and side-steps problems 3, 4 and 5.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 5, 2018

Member

FWIW, I like that stance, given that it'll be hard enough to even get that defined and shipped, but I do wonder how we'd later move to scripted files, if deemed needed after all. Perhaps we'd simply mint another MIME type though, doesn't seem like it'd be the end of the world.

Member

annevk commented Oct 5, 2018

FWIW, I like that stance, given that it'll be hard enough to even get that defined and shipped, but I do wonder how we'd later move to scripted files, if deemed needed after all. Perhaps we'd simply mint another MIME type though, doesn't seem like it'd be the end of the world.

@GrosSacASac

This comment has been minimized.

Show comment
Hide comment
@GrosSacASac

GrosSacASac Oct 5, 2018

@dandclark Overall I like the proposal a lot. Making every script type="module" is clever, because it makes everything simpler.

@AshleyScirra import.meta.document being limited to inline script is good design for at least 2 reasons:

First, js modules can be imported multiple times, from js or html and having import.meta.document would be inconsistent in such cases. Second, the js module can import its owner html module. That would be predictable because every type="module" js is async by default, so that circular import would work.

Another way to have import.meta.document in a web component architecture, would be to use dependency injection: Having one file importing both html and appropriate js module and initiating the js module with the html default import which is exactly import.meta.document.

If I understand correctly, the role of the inline script in a html module would be to expose more precise html elements, than just the document. Everything else can be done in normal js module imported by the main js module on the page.

GrosSacASac commented Oct 5, 2018

@dandclark Overall I like the proposal a lot. Making every script type="module" is clever, because it makes everything simpler.

@AshleyScirra import.meta.document being limited to inline script is good design for at least 2 reasons:

First, js modules can be imported multiple times, from js or html and having import.meta.document would be inconsistent in such cases. Second, the js module can import its owner html module. That would be predictable because every type="module" js is async by default, so that circular import would work.

Another way to have import.meta.document in a web component architecture, would be to use dependency injection: Having one file importing both html and appropriate js module and initiating the js module with the html default import which is exactly import.meta.document.

If I understand correctly, the role of the inline script in a html module would be to expose more precise html elements, than just the document. Everything else can be done in normal js module imported by the main js module on the page.

@AshleyScirra

This comment has been minimized.

Show comment
Hide comment
@AshleyScirra

AshleyScirra Oct 5, 2018

Having one file importing both html and appropriate js module and initiating the js module with the html default import which is exactly import.meta.document

Or, just let the JS module import the HTML file itself?

Also if you use a CSP without 'unsafe-inline', wouldn't this completely block the use of import.meta.document at all?

AshleyScirra commented Oct 5, 2018

Having one file importing both html and appropriate js module and initiating the js module with the html default import which is exactly import.meta.document

Or, just let the JS module import the HTML file itself?

Also if you use a CSP without 'unsafe-inline', wouldn't this completely block the use of import.meta.document at all?

@jkrems

This comment has been minimized.

Show comment
Hide comment
@jkrems

jkrems Oct 5, 2018

When reading the exports part I got super excited for a second but then I ran into the <script> tag. I think it would be super interesting to make "export by (HTML) id" the default. Then HTML imports could focus on being exactly HTML markup and it would be possible to cleanly split the code pieces:

<!-- export myCustomElementTemplate -->
<template id="myCustomElementTemplate">
    <div class="myDiv">
        <div class="devText">Here is some amazing text</div>
    </div>
</template>

And the component lives in a simple .js file:

import { myCustomElementTemplate as template } from './see-above.html';
 
class myCustomElement extends HTMLElement {
  constructor() {
    super();
    let shadowRoot = this.attachShadow({ mode: "open" });
    shadowRoot.appendChild(template.content.clone(true));
  }
}
window.customElements.define("myCustomElement", myCustomElement);

jkrems commented Oct 5, 2018

When reading the exports part I got super excited for a second but then I ran into the <script> tag. I think it would be super interesting to make "export by (HTML) id" the default. Then HTML imports could focus on being exactly HTML markup and it would be possible to cleanly split the code pieces:

<!-- export myCustomElementTemplate -->
<template id="myCustomElementTemplate">
    <div class="myDiv">
        <div class="devText">Here is some amazing text</div>
    </div>
</template>

And the component lives in a simple .js file:

import { myCustomElementTemplate as template } from './see-above.html';
 
class myCustomElement extends HTMLElement {
  constructor() {
    super();
    let shadowRoot = this.attachShadow({ mode: "open" });
    shadowRoot.appendChild(template.content.clone(true));
  }
}
window.customElements.define("myCustomElement", myCustomElement);
@AshleyScirra

This comment has been minimized.

Show comment
Hide comment
@AshleyScirra

AshleyScirra Oct 5, 2018

I think exporting element IDs by default will make it difficult to extend the feature later down the line if we do want to make HTML modules export their own dependencies. It's just an extra call to getElementById if you have the doc, e.g.:

import doc from "./see-above.html";
const myCustomElementTemplate = doc.getElementById("myCustomElementTemplate");

Then we've not locked the feature in to a specific kind of default export that is difficult to change in future.

In other words - how about we ship a basic static import of HTML and see how things pan out from there? I think this was already previously suggested, but this thread is getting a bit long now, it's hard to check...

AshleyScirra commented Oct 5, 2018

I think exporting element IDs by default will make it difficult to extend the feature later down the line if we do want to make HTML modules export their own dependencies. It's just an extra call to getElementById if you have the doc, e.g.:

import doc from "./see-above.html";
const myCustomElementTemplate = doc.getElementById("myCustomElementTemplate");

Then we've not locked the feature in to a specific kind of default export that is difficult to change in future.

In other words - how about we ship a basic static import of HTML and see how things pan out from there? I think this was already previously suggested, but this thread is getting a bit long now, it's hard to check...

@alexgwolff

This comment has been minimized.

Show comment
Hide comment
@alexgwolff

alexgwolff Oct 5, 2018

@AshleyScirra But you can do this? No?

import * as doc from "./see-above.html";
const myCustomElementTemplate = doc.getElementById("myCustomElementTemplate");

alexgwolff commented Oct 5, 2018

@AshleyScirra But you can do this? No?

import * as doc from "./see-above.html";
const myCustomElementTemplate = doc.getElementById("myCustomElementTemplate");
@justinfagnani

This comment has been minimized.

Show comment
Hide comment
@justinfagnani

justinfagnani Oct 5, 2018

@dandclark thanks for the proposal, it's very exciting to have some implementor interest and alignment here!

Overall this looks really good. It looks like it mostly subsets what I was proposing and sidesteps some tricky questions around exports from HTML. Nice :)

One feedback about import.meta.document: I think import.meta.scriptElement would be more useful, and has the same constraints that it would need to be available only in inline modules.

There are patterns where a script may want to know it's location in a document, say:

<awesome-element name="MyElement">
  <template>...</template>
  <script>
    class MyElement extends AwesomeElement {
      static script = import.meta.scriptElement;
    }
  </script>
<awesome-element>

Here AwesomeElement finds the template (or other DOM resources) with something like:

this.constructor.script.parentElement.querySelector('template');

Of course there are other ways to arrange things for similar effect (require ids, add a HTMLScriptElement.module property, etc.), but as long as we add the constraint that this in only available in inline modules I think we might as well go all the way to the script element.

justinfagnani commented Oct 5, 2018

@dandclark thanks for the proposal, it's very exciting to have some implementor interest and alignment here!

Overall this looks really good. It looks like it mostly subsets what I was proposing and sidesteps some tricky questions around exports from HTML. Nice :)

One feedback about import.meta.document: I think import.meta.scriptElement would be more useful, and has the same constraints that it would need to be available only in inline modules.

There are patterns where a script may want to know it's location in a document, say:

<awesome-element name="MyElement">
  <template>...</template>
  <script>
    class MyElement extends AwesomeElement {
      static script = import.meta.scriptElement;
    }
  </script>
<awesome-element>

Here AwesomeElement finds the template (or other DOM resources) with something like:

this.constructor.script.parentElement.querySelector('template');

Of course there are other ways to arrange things for similar effect (require ids, add a HTMLScriptElement.module property, etc.), but as long as we add the constraint that this in only available in inline modules I think we might as well go all the way to the script element.

@matthewp

This comment has been minimized.

Show comment
Hide comment
@matthewp

matthewp Oct 5, 2018

-1 on the exporting by id idea. We already have something similar with the named access on the window object feature and it causes a lot of problems. ids already have other uses. A more explicit export-as attribute could be nice, but I would hope that we don't overcomplicate the v1 of HTML modules.

matthewp commented Oct 5, 2018

-1 on the exporting by id idea. We already have something similar with the named access on the window object feature and it causes a lot of problems. ids already have other uses. A more explicit export-as attribute could be nice, but I would hope that we don't overcomplicate the v1 of HTML modules.

@AshleyScirra

This comment has been minimized.

Show comment
Hide comment
@AshleyScirra

AshleyScirra Oct 5, 2018

I really think the fact a good CSP blocks inline scripts should be a deal-breaker for any inline-script-only feature.

@alexgwolff - oops, yes, typo in my code.

AshleyScirra commented Oct 5, 2018

I really think the fact a good CSP blocks inline scripts should be a deal-breaker for any inline-script-only feature.

@alexgwolff - oops, yes, typo in my code.

@justinfagnani

This comment has been minimized.

Show comment
Hide comment
@justinfagnani

justinfagnani Oct 5, 2018

@AshleyScirra CSP could evolve to treat HTML modules with the same policy as script. HTML is only considered less secure because it's more often server generated, but there's no reason why .js files couldn't have XSS holes in them too.

justinfagnani commented Oct 5, 2018

@AshleyScirra CSP could evolve to treat HTML modules with the same policy as script. HTML is only considered less secure because it's more often server generated, but there's no reason why .js files couldn't have XSS holes in them too.

@davatron5000

This comment has been minimized.

Show comment
Hide comment
@davatron5000

davatron5000 Oct 5, 2018

One question that I have after reading the proposal is how would I import and use custom elements in this paradigm?

import.html

<template id="myCustomElementTemplate">...</template>
<script type="module">
   // custom Element setup
  window.customElements.define("my-element", myCustomElement);
</script>

main.html

<my-element> .. </my-element>
<script type="module">
	import { myElement } from "import.html"
	// ???????????????????????????????????????
</script>

Would the import just work? Or would there need to be some plumbing?

davatron5000 commented Oct 5, 2018

One question that I have after reading the proposal is how would I import and use custom elements in this paradigm?

import.html

<template id="myCustomElementTemplate">...</template>
<script type="module">
   // custom Element setup
  window.customElements.define("my-element", myCustomElement);
</script>

main.html

<my-element> .. </my-element>
<script type="module">
	import { myElement } from "import.html"
	// ???????????????????????????????????????
</script>

Would the import just work? Or would there need to be some plumbing?

@dandclark

This comment has been minimized.

Show comment
Hide comment
@dandclark

dandclark Oct 6, 2018

Thanks everyone for the feedback so far! I want to address some points that were raised in the first round of comments.

  1. @AshleyScirra, @annevk, @GrosSacASac, and @justinfagnani provided some feedback on import.meta.document. There seem to be 3 possibilities: (A) Keep import.meta.document as in our original proposal, (B) Switch to import.meta.scriptElement with the same constraints, or (C) eliminate it altogether in favor of the approach below where a JS module re-imports its owner HTML Module as pointed out by @GrosSacASac:

import.html:

<template id="myTemplate">
  ...
</template>
<script type="module">
  import importDoc from "./import.html";
  let template = importDoc.getElementById("myTemplate");
  ...
</script>

Approach B as pointed out by @justinfagnani makes sense if we expect an inline module to need access to its script element’s location. Is that really a common pattern though? This could be worked around with known ids, querySelector etc. We had initially proposed (A) given that we expect access to the document to be the more common use case, and import.meta.document is shorter than import.meta.scriptElement.ownerDocument. I’d like to learn a bit more about which we expect to be the common use case here. Overall, import.meta.document seems like a developer convenience feature and could be eliminated to simplify the proposal. We’re open to any of these possibilities at this point.

  1. @AshleyScirra had a point on keeping HTML modules limited to static content. I think that our proposal doesn't limit developers from adopting static-only content as a convention, but our preference is to not prevent devs from including a script module into an HTML module. The example above wouldn't be possible, and the simplicity of being able to author a single file component that has declarative content seems like an appealing use case.

  2. We're open to the idea that @jkrems brought up, where the HTML module exports elements based on id or an 'export' attribute. However our main point in using inline scripts to create exports for an HTML module is that it addresses the "export pass through" problem. If I want to author a single page widget that includes declarative content, then how can I import a JavaScript API from that widget? The answer we're proposing is below... inline script exports have a new purpose when used in an HTML module.

index.html:

<script type="module">
    import {widgetAPI} from "./widget.html"
    widgetAPI.use()
</script>

widget.html

<template id="widgetTemplate">
   ...
</template>
<script type="module">
    let widgetAPI = ...
    export {widgetAPI}
</script>
  1. @davatron5000: For that case a simple import "./import.html" would work. The window.customElements.define call runs in main.html’s realm and thus <my-element> can be used in main.html without any other explicit plumbing.

dandclark commented Oct 6, 2018

Thanks everyone for the feedback so far! I want to address some points that were raised in the first round of comments.

  1. @AshleyScirra, @annevk, @GrosSacASac, and @justinfagnani provided some feedback on import.meta.document. There seem to be 3 possibilities: (A) Keep import.meta.document as in our original proposal, (B) Switch to import.meta.scriptElement with the same constraints, or (C) eliminate it altogether in favor of the approach below where a JS module re-imports its owner HTML Module as pointed out by @GrosSacASac:

import.html:

<template id="myTemplate">
  ...
</template>
<script type="module">
  import importDoc from "./import.html";
  let template = importDoc.getElementById("myTemplate");
  ...
</script>

Approach B as pointed out by @justinfagnani makes sense if we expect an inline module to need access to its script element’s location. Is that really a common pattern though? This could be worked around with known ids, querySelector etc. We had initially proposed (A) given that we expect access to the document to be the more common use case, and import.meta.document is shorter than import.meta.scriptElement.ownerDocument. I’d like to learn a bit more about which we expect to be the common use case here. Overall, import.meta.document seems like a developer convenience feature and could be eliminated to simplify the proposal. We’re open to any of these possibilities at this point.

  1. @AshleyScirra had a point on keeping HTML modules limited to static content. I think that our proposal doesn't limit developers from adopting static-only content as a convention, but our preference is to not prevent devs from including a script module into an HTML module. The example above wouldn't be possible, and the simplicity of being able to author a single file component that has declarative content seems like an appealing use case.

  2. We're open to the idea that @jkrems brought up, where the HTML module exports elements based on id or an 'export' attribute. However our main point in using inline scripts to create exports for an HTML module is that it addresses the "export pass through" problem. If I want to author a single page widget that includes declarative content, then how can I import a JavaScript API from that widget? The answer we're proposing is below... inline script exports have a new purpose when used in an HTML module.

index.html:

<script type="module">
    import {widgetAPI} from "./widget.html"
    widgetAPI.use()
</script>

widget.html

<template id="widgetTemplate">
   ...
</template>
<script type="module">
    let widgetAPI = ...
    export {widgetAPI}
</script>
  1. @davatron5000: For that case a simple import "./import.html" would work. The window.customElements.define call runs in main.html’s realm and thus <my-element> can be used in main.html without any other explicit plumbing.
@BoCupp-Microsoft

This comment has been minimized.

Show comment
Hide comment
@BoCupp-Microsoft

BoCupp-Microsoft Oct 22, 2018

@dandclark and @samsebree are working on a prototype of the concepts outlined in Dan's initial post. We thought it would be a good idea to track what changes we anticipate needing to make to existing specifications to make it work. Here's a document outlining the changes we've identified thus far. Thanks in advance for taking time to review it.

BoCupp-Microsoft commented Oct 22, 2018

@dandclark and @samsebree are working on a prototype of the concepts outlined in Dan's initial post. We thought it would be a good idea to track what changes we anticipate needing to make to existing specifications to make it work. Here's a document outlining the changes we've identified thus far. Thanks in advance for taking time to review it.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Oct 22, 2018

Contributor

@BoCupp-Microsoft that is great work, thank you! On the ES spec changes in particular, I'll note that web assembly is paving us a very helpful path here. In particular they're doing some of the refactoring you allude to in tc39/ecma262#1311. With that in place we should be able to define a HTML Module Record type in HTML or similar.

Still skimming the rest of the document, but really impressive to see this level of detail!

Contributor

domenic commented Oct 22, 2018

@BoCupp-Microsoft that is great work, thank you! On the ES spec changes in particular, I'll note that web assembly is paving us a very helpful path here. In particular they're doing some of the refactoring you allude to in tc39/ecma262#1311. With that in place we should be able to define a HTML Module Record type in HTML or similar.

Still skimming the rest of the document, but really impressive to see this level of detail!

@BoCupp-Microsoft

This comment has been minimized.

Show comment
Hide comment
@BoCupp-Microsoft

BoCupp-Microsoft Oct 23, 2018

@domenic thank you for the feedback - the cyclic module record refactoring looks helpful. Also, I agree its great work ;-), but want to point out that @dandclark did all the heavy lifting to author that document so that the credit lands where it should.

BoCupp-Microsoft commented Oct 23, 2018

@domenic thank you for the feedback - the cyclic module record refactoring looks helpful. Also, I agree its great work ;-), but want to point out that @dandclark did all the heavy lifting to author that document so that the credit lands where it should.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment