without .html in link rel="import" and href in web component

ghost commented 1 year ago

Hi everyone.

I would like to know if there would be a possibility to create a link rel="import" href= without .html in web component

before_example.html

<!doctype html>
<html>
<head>
    <meta charset="utf-8">
    <title>Cdn and web components</title>
    <!-- Imports polyfill with cdn external -->
    <script src="https://samplecdn1.com/ajax/libs/webcomponents/webcomponents-lite.min.js"></script>
    <!-- Imports custom element with cdn external -->
    <link rel="import" href="https://samplecdn2.com/ajax/libs/webcomponents/hello-world.html">
</head>
<body>
    <!-- Runs custom element from samplecdn1, samplecdn2-->
    <hello-world who="Unicorn"></hello-world>
</body>
</html>

after_example.html

<!doctype html>
<html>
<head>
    <meta charset="utf-8">
    <title>Cdn and web components</title>
    <!-- Imports polyfill with cdn external -->
    <script src="https://samplecdn1.com/ajax/libs/webcomponents/webcomponents-lite.min.js"></script>
    <!-- Imports custom element with cdn external without .html -->
    <link rel="import" href="https://samplecdn2.com/ajax/libs/webcomponents/hello-world">
</head>
<body>
    <!-- Runs custom element from samplecdn1, samplecdn2-->
    <hello-world who="Unicorn"></hello-world>
</body>
</html>

why?

there are cdn's that don't allow to have .html files in the web component as cdnjs

sashafirsov commented 1 year ago

This is a particular case of hydrate="onClientLoad" in proposal https://github.com/webcomponents-cg/community-protocols/issues/30 Hydration is a generic mechanism of web components life cycle. Once external resources like templates would become part of Declarative Web Component or Declarative Shadow DOM, it would be responsible for dependencies including html templates/web components loading.

ghost commented 1 year ago

Hi sashafirsov. thank you for feedback. But... what do you think of this idea? without .html in link rel="import" and href in web component?

sashafirsov commented 1 year ago

@codehangen , I like the idea but it has to be extended in order to be useful as connecting external resource with local content.

If you along with URL would provide the local component name(s) mapping to declared name(s) in external HTML, that would be even more useful. Similar to import maps or JS import with mapping external export to local import.

Now about link which would define the custom element(s). For JS, there is no need to import as there is a script tag for that. If link points to HTML, it would have define CE as Declarative Custom Element or HTML with JS for custom element definitions.

If you want to load HTML with JS, you need to count on current resurrection of HTML include proposal. Whether the HTML would have the web component(s) registration or just some JS, is irrelevant to web components themselves.

HTML without JS could define CE as Declarative Custom Element. The proposal is not yet shaped. So your proposal has a dependency on this standard to be. Or you had in mind different way of declaring CE?

There is a row of alternative proposals of light version of CE : have a DSD <template src="my-template.html"> as inline custom element substitution.

or DCE <element template="my-template.html" name="my-component">.

For both JS use protocol is in baking.

ghost commented 1 year ago

Hi sashafirsov, so thank you for feedback.

If you along with URL would provide the local component name(s) mapping to declared name(s) in external HTML, that would be even more useful. Similar to import maps or JS import with mapping external export to local import.

yes, exactly. so I was thinking about this idea.

HTML without JS could define CE as Declarative Custom Element. The proposal is not yet shaped. So your proposal has a dependency on this standard to be.

I was thinking about this idea too.

sashafirsov commented 1 year ago

why? there are cdn's that don't allow to have .html files in the web component

I would not count it as a good argument. The .html extension and extension of file in the web server world replaced with a bit more strict content-type. But the module mapping (similar to import maps in JS) is one of important parts of Declarative Web Application. The consumer module would refer the dependency by symbolic name and loader would use import maps to resolve it to CDN URL. The semver CDN server then would resolve it to final URL.

ghost commented 1 year ago

Hi sashafirsov, so thank you for the feedback.

If you want to load HTML with JS, you need to count on current resurrection of HTML include proposal. Whether the HTML would have the web component(s) registration or just some JS, is irrelevant to web components themselves.

so... what do you think of this idea? it is possible?

sashafirsov commented 1 year ago

@codehangen , IMO yes, it is possible. The without .html could and should be taken off the proposal subject. You are asking the loading web component by link rel="import" and href

As stated the extension is not relevant, you could load JS content even if it has .png extension or without extension completely but returned by server with "application/javascript" content type.

The proposal need to be accompanied by content type for Declarative Custom Element(DCE) as html( not sure what content type) or html document(application/html) with multiple custom elements definitions.

PS. I am same wonderer in the standards as you are and do not have mush background to advise how to pursue further.

PPS. The ability to load web component via declarative definition by URI is a requirement for Declarative Web Application stack which I am working on at the moment. The URI could refer as single DCE definition as multiple. It is a straight match to JS es6 module with default export and named ones. The import you proposing has to cover all necessary use cases

default import
import by name(s)
ability to redefine names locally
hide the variables(custom element definitions) when imported so the internals of imported module would not pollute the namespace of the module where the import used.
the import maps kind of orthogonal, it is applied to resolve URI

ghost commented 1 year ago

Hi sashafirsov, again, thanks for the feedback.

I like the idea but it has to be extended in order to be useful as connecting external resource with local content

but what did you mean by that?

sashafirsov commented 1 year ago

@codehangen, take the analog for import JS with some object inside ( i.e. custom element with associated tag ). If you import "some.js" its content meant to be anonymous to prevent names pollution and collision.

Same with import HTML as custom elements. The tags inside should not pollute the caller namespace.

In order to be consumed by caller import MyComponent from "some.js" would define what name to be used for exported from some.js object.

For import of custom element it would need similar possibility: <link rel="import" href="some.html" tag="imported-component" />

That way you are assured that whatever Custom Element tag chosen within some.html , it would not be trashing caller HTML.

What about more than one Custom Element and tags are served by some.html?

It would need the syntax siminal to ESM

import { MyComponent as ImportedComponent, AnotherComponent as Imported2} from "some.js";

Of course in HTML syntax.

WICG / webcomponents