Re: [w3c/webcomponents] HTML Modules (#645)

I wrote [this blog post](https://www.scirra.com/blog/ashley/34/html-imports-are-the-best-web-component). 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!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/645#issuecomment-310054056