-
Notifications
You must be signed in to change notification settings - Fork 57
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 #334
Comments
@dandclark @samsebree @travisleithead @BoCupp-Microsoft First of all, I really welcome this feature and the great detailed explainer. In the line of, now postponed declarative shadow dom, I believe HTML modules to become popular by designers etc, at least if they can stay within the realm of HTML and CSS and thus avoid "coding" JavaScript. I think it is valid to consider this case and I see that there is already an issue filed about a declarative way to export (MicrosoftEdge/MSEdgeExplainers#9). As you allow multiple exports (like ECMAScript Modules), this makes it a valid target for dead "code" elimination and "code" splitting (dead content elimination and content splitting? :-)) - I don't know what is needed to make that work well, but I believe it is important to consider, especially because if it is not possible, you will see developers arguing for just using scripts instead (CSS-in-JS etc) |
This has been brought up here but it really feels like non-script use cases should be covered. Another thing that came to mind is how this would work in a non-web context (e.g. node.js) since module support is a feature there, and would be a bit hard to implement as a third-party library. (That said, I really like this feature.) |
I'm not sure I understand what you mean here, can you clarify (perhaps with an example)? |
<!doctype html>
<html>
<template id="one">
...
</template>
<template id="two">
...
</template>
<script type=module>
const one = import.meta.document.getElementById("one");
const two = import.meta.document.getElementById("two");
export { one, two }
</script>
</html> <!doctype html>
<html>
<head>
<title>HTML Modules Demo</title>
<script type="module">
import { one } from "./one-and-two.html";
// do stuff with 'one', but never import and use 'two'
</script>
</head>
<body>
...
</body>
</html> As I am only using the 'one' template, tooling should be able to treeshake and provide the first time as just containing 'one' given that I never use 'two' in the project. This is commonly done in JS today with tools like WebPack, and it is important that we don't do anything making it impossible or hard to treeshake or to dead code elimination |
I do hope that |
As far as I was told, the current focus is on first doing JSON modules, then CSS modules and then revisit HTML modules. So we are changing progress to stalled until work re-starts on HTML modules. When that happens, please ping us here |
Since HTML Modules (like CSS and JSON Modules) is waiting on tc39/proposal-import-attributes to advance, we're going to close this review for now. Please file a new one or have us re-open this one once HTML Modules is un-blocked. Thanks! |
tc39/proposal-import-attributes no longer blocks this. |
As been mentioned by HTML modules - problem statement , The pure declarative implementation can rely completely on referencing the template( or any another element) DOM subtree. Same is applicable when importing from JS. Such approach is working for declarative and JS use. |
こんにちはTAG!
I'm requesting a TAG review of:
Further details (optional):
We'd prefer the TAG provide feedback as (please select one):
The text was updated successfully, but these errors were encountered: