Re: [WICG/webcomponents] Exploration: HTML Module Imports and Exports (Issue #1059)

I tend to think that importing and doing things with the imports should be separated. Then you have a general mechanism for defining and consuming identifiers, and many features can plug into either side of that.

So I'd prefer to have an import just define a identifiers*, and something like a scoped custom element registry just use those identifiers. I don't think an import should also define a custom elements - that seems too coupled.

### Importing identifiers

An import could allow you to import one or more identifiers from the module, and define a identifiers in some HTML scope:

```html
<import src="./element-one.html" imports="element-one element-two"></import>
```

Because we want an equivalence between JS and HTML modules, this should work with JS too:

```html
<import src="./element-one.js" type="js" imports="element-one element-two"></import>
```

I think this might be a reason to not use fragments in the imports. Though maybe when you import from JS, the fragments just reference exports?

_Note that `type="js"` is similar to import attributes, but the default is flipped, because we might want HTML modules to be the default for `<import>`._

Another option is to just use the existing `<script>` tag, but allow it to import identifiers:

```html
<script src="./element-one.html" type="html" imports="element-one"></script>
```

If we want to meet the use case of running with JavaScript disabled, could we say that `type="html"` is allowed if it doesn't contain or import JS itself?

* We need to define exactly what an "identifiers" is. Is it an id and works with idrefs? Is it a separate namespace from ids? Is there some kind of "lexical" scoping mechanism for identifiers to facilitate bundling?

### Declaring local identifiers

We want HTML modules to be able to be be bundled and to just naturally be able to contain multiple component definitions. So we don't want to have to import an identifier, but also be able to declare them locally:

```html
<!-- Defines, but does not register, a custom element class -->
<define id="element-one">...</define>
```

_Note: I'm using the `id` attribute here. Can we just reuse IDs for identifiers? It'd be simpler conceptually_

### Using identifiers

Once we have a way to import or declare identifiers, we have unlocked HTML use-cases for non-side-effectful HTML modules. We can import a definition and register it ourselves:

```html
<script src="./element-one.html" type="html" imports="element-one"></script>
<define id="element-two">
  <registry>
    <define tagname="el-one" from="element-one">
  </registry>
  <template>
    <el-one></el-one>
  </template>
</define>
```

Note I'm overloading `<define>` here to define an element globally when it's not a child of a `<registry>` and to define an element inside a scoped registry when it is. The example also implies that a declarative custom element definition just implicitly uses the first `<registry>` child. We would need a way to reference shared registries too.

We could also just import templates from a separate file:

```html
<script src="./template.html" type="html" imports="template-one"></script>
<define id="element-one">
  <template from="template-one"></template>
</define>
```

Or maybe:

```html
<script src="./template.html" type="html" imports="template-one"></script>
<define id="element-one" template="template-one">
</define>
```


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

Message ID: <WICG/webcomponents/issues/1059/2093743324@github.com>