[declarative-custom-elements] shorter syntax

[trusktr]

If we're going to add special attributes to template, like shadowmode which is specifically for custom elements (right?) then why not use template for the custom element definition without and extra definition element (less nesting)?

F.e. instead of

<definition name="percentage-bar">
    <template shadowmode="closed">
        <div>...</div>
        <style>/*...*/</style>
    </template>
    <script type=module>
        export default class MyEl extends HTMLElement { /*...*/ }
    </script>
</definition>

We could write the following more simple version:

<template element="percentage-bar" shadowmode="closed">
    <div>...</div>
    <style>/*...*/</style>
    <script type=module>
        export default class MyEl extends HTMLElement { /*...*/ }
    </script>
</template>

Would that be too conflicting with how template currently works?

If it isn't feasible to use template that way for technical reasons of the browser (f.e. the parser implementation, or something), then what about something like

<element name="percentage-bar" shadowmode="closed">
    <div>...</div>
    <style>/*...*/</style>
    <script type=module>
        export default class MyEl extends HTMLElement { /*...*/ }
    </script>
</element>

Hmmm. 🤔, I really like the <element> naming. Perhaps all content inside <element>, except for script tags, is treated the same as (or similar to) a <template>?

From a developer experience perspective, the less to write the better.

[justinfagnani]

Neither of those options are feasible.

In the first variant, you can't put the <script> inside the <template>. We need the script to be run once to augment the element definition, and potentially before the first instance is created. The <template> would be cloned per-instance.

In the second variant, we really do need a <template> element to contain the potential DOM for instances. We don't want live elements there - images and iframes loading, styles applying, etc.

What's wrong with the original example? Yes, there's an outer element, but it's all very explicit and follows expectations of how the elements already behave.

[trusktr]

I see what you mean. There's nothing wrong with it. I was only wondering if there's a less verbose way to do it.

What if with

<element name="percentage-bar" shadowmode="closed">
    <div>...</div>
    <style>/*...*/</style>
    <script type=module>
        export default class MyEl extends HTMLElement { /*...*/ }
    </script>
</element>

the script runs once, but all other content of the <element> element is treated like template content for each instance?

If we could do that, then we could also extend the functionality to the following.

In one file, my-el.html:

<div>...</div>
<style>/*...*/</style>
<script type=module>
    export default class MyEl extends HTMLElement { /*...*/ }
</script>

In another file that uses it:

<element name="my-el" src="./my-el.html" />

which is appealing.

In contrast, with the <definition> element and separate <template> element, every file would have an extra wrapper:

my-el.html would be:

<template>
  <div>...</div>
  <style>/*...*/</style>
</template>
<script type=module>
    export default class MyEl extends HTMLElement { /*...*/ }
</script>

and the consumer would be:

<definition name="my-el" src="./my-el.html" />

---

Even if the original idea is the only way to do it, the name <element> is more enjoyable than <definition>. It really hits a sweet spot. F.e.:

<element name="my-el">
    <template>
        <div>...</div>
        <style>/*...*/</style>
    </template>
    <script type=module>
        export default class MyEl extends HTMLElement { /*...*/ }
    </script>
</element>

---

I'm on the fence though. Regardless, writing "single-file elements" is gonna be neat.

[keithamus]

WCCG had their spring F2F in which this was discussed. You can read the full notes of the discussion (WCCG had their spring F2F) in which this was discussed, heading entitled "Declarative Templating & Custom Elements".

This was briefly discussed as part of that topic. The consensus from present members of the WCCG was that more use cases need to be captured around this area, in order to clarify what these proposals solve.