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

@justinfagnani , @dglazkov  let take a look into root cause of the need for such html imports, how it was addressed in history and what is really missing in given proposal.

The imports for different content types has been in demand since HTML appearance. Except of initially they been addressed differently in own "tiers" and there was no systematic/unified approach. IFrame, CSS, images in HTML, of course SCRIPT of few kinds, etc.

That combination of not unified load and consuming resources have created the need for unification as the volume of web apps simply could not be supported by such approach. Industry have developed the work around as site builders and later build toolchains which been treated resources in same fashion - from registry/dependency tree to loading. 
```javascript
import './mystyles.scss`
import `@typography/spacing.scss`
import `@typography/roboto.ttf`
import scopedDef from `./myCssMod.scss`
import logo from './app.svg'
import headerTemplate from './headerTemplate.html`
...
```  
images, fonts, images, html templates are been treated alike by WebPack, RollUp, and other build toolchains. 
Those have served as loading depend of content type as module location resolution as chain of transformations before delivering into final content:

SASS been compiled into CSS, than converted either to LINK or STYLE. Along the way it also been massaged to add compatibility layers or virtually any programmable functionality.

Similar transformation is done for images and fonts. 

If we are going to tackle little problems like HTML imports or import maps in insulation from whole delivery chain, the standard would prevent the concept extension into already existing patterns proven to be in high demand ( build toolchains) in web platform. Rather 'html', 'import maps', etc. we need from browser platform the layers of functionality needed for complex Web 3.0. 

The module resolvers capable of working with semver CDNs with integrity in mind: `package.json` functionality in browser for each loaded module, not the import maps. With ability to override in app the externally defined dependencies( missing in NPM/yarn). 

The loader with pre- and post- processing transformation chain driven by the changing along content type.  

The container capable of insulation layers from CSS to JS gradually exposing or hiding internals.  

And so on, everything which we are currently utilize as app build framework but in browser. The idea is not new: build toolchains running in browser are known more than decade. Question is `how to make it right?`.

The html import here is just a string loader as I see it. The import as module could treat itself or its parts in several different ways:
* as html string
    ```JS
    import myTemplate from './myTemplate.html`
    el.innerHTML = `...${ myTemplate } ...`
    ```
* as loaded template DOM
    ```JS
    import myTemplateDom from './myTemplate.html`
    el.append(myTemplateDom)
    ```
* exported parts as template slots 
    ```JS
    import pendigAnimation from './loading.smil`
    import myTemplateDom,{ loadingSlot, dataSlot } from './myTemplate.html`
    loadingSlot = pendigAnimation;// would instantiate myTemplateDom and set slot
    el.append(myTemplateDom)
    ```
* exported parts as slot setters for template object ( imported object evaluated to template **clone** DOM with toString() to HTML and with slot setters )
    ```JS
    import pendigAnimation from './loading.smil`
    import myTemplate,{ loadingSlot, dataSlot } from './myTemplate.html`
    loadingSlot = pendigAnimation;// would instantiate myTemplate and set slot
    el.innerHTML = `...${ myTemplate } ...` // autoconverted to string
    ```

and so on. 

Taking/picking one or another side of implementation now would mean 100% **future deprecation**! 

Instead, the page and particular module should have ability to control ( or point to external descriptor ) the content-type driven transformation. The app developer would pick or define the way this transformation happen. And consumer JS or HTML would be written according to defined transformation chain. 

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