Templating in HTML

lit-html is great. I use it for a lot of projects whenever I need some simple tempted HTML. That being said, it seems like the v1 documentation for lit-html [1] has been removed in favor of a single page in the v2 documentation [2]. Is using lit-html standalone not recommended anymore? I really liked using it standalone.

[1] https://lit.dev/docs/v1/lit-html/introduction/ [2] https://lit.dev/docs/libraries/standalone-templates/

I use lit-html for front end projects at work and it's a godsend, truly. Being able to keep one central 'state' object and just re-render a template based on that without having to pull in a whole framework, without having to set up a whole webpack build process, is incredible!

Do you have a link to the template instantiation proposal?

> But I really wish there were an HTML-native way to load <template> from separate files

Seems like the JS folks blocked this from happening. It's weird to me to think we've arrived at the point where JS considerations have come to dominate for something that was built to be a document sharing platform.

Yes, I thought that's what this article would be about. Respectfully, the MDN reference for <template> has more information than this post.

There's no lack of syntactical templating mechanisms when HTML is hosted within a SGML markup processing context (ie how HTML started life), and no need to add templating at the HTML markup vocabulary level either:

For server-side rendering, SGML (and also some other template "engines") provide HTML-aware, type-checked, parametric macro expansion. Actually, SGML templating works transparently on the client side and the server side.

Within the browser OTOH, there's already JavaScript, making every dynamic feature added to HTML inessential for better or worse, like it has for over 25 years now. That's just how it was decided a long time ago, and adding half-assed features to HTML like the template element (which requires JavaScript, in turn, thus doesn't add any essential capability) all the time is exactly the thing we shouldn't be doing when the damn "web stack" is already bloated as fuck.

Because JS is where the privacy holes are at and keep getting added.

<template> is special, very different from display: none; and definitely has a few advantages:

- The elements in it are parsed into a different document and are inert until cloned or adopted into the main document. Images don't load, scripts don't run, styles don't apply, etc. This is very important.

- The content model validation is turned off, so a <template> can contain a <td>

- Mutation observers and events are not fired for parsed content.

- The <template> element itself can appear anywhere, including restricted content elements like <table>

- Other HTML processing libraries generally know to ignore <template>, unlike other content just hidden with CSS.

This makes parsing faster and guaranteed to have no side effects, and conveys the correct semantics to the browser and tools.

I think the main advantages are that you don't have to remember to add "display:none", and that it gives the structure more semantic meaning. If I look at your code and see "display:none", I don't know why you've chosen to hide it. If it's wrapped in a <template> element, I instantly know why it's not being displayed as I now have an idea of how it's going to be used.

If I recall correctly there are some subtle things you cannot achieve without <template>.

<img> inside <template> is not attempted to be loaded because “it presents nothing in rendering”

https://html.spec.whatwg.org/multipage/scripting.html#the-te...

> for example a dialog box

The <dialog> element is now supported by all modern browser. I suggest you use it. It has a lot of niceties over implementing one your self, including capturing the focus, correct announcing to assistive technologies, styling the ::backdrop element, etc.

I think it's mostly performance as the browser can add performance optimisations for HTML but not unevaluated JavaScript.

The alternative is a "display: none" block, but that triggers a calculation of styles, where <template> can never be rendered so it's evaluated (likely in parallel to JS) by the browser without style calculations.

The optimisations lose weight if the <template> tag is added programatically later. For it to be maximally efficient; all of the <template> tags must be inlined in your HTML prior to your application loading. You can play around with loading it asynchronously to ensure nothing blocks.

Front end web is not my forte, but as I understand display:none; can have unintended (usually negative) interactions with screen readers, which I don't believe is a possibility with HTML templates.

<template> (along with <slot>) allows for a declarative shadow DOM instead of clunky attachShadow()s on hidden <div>s (which doesn't work server-side)

Otherwise you probably don't need <template>, in fact they don't handle events the same as the rest of the DOM and will likely cause more pain

I assume content within "display:none" will be read by search engines and viewed in source. Is <template> read by search engines?

> With substitution variables/text, this feature could be amazing.

At which point, are you just re-creating JavaScript?

Here's what I got:

    const $template = function(template) {
        // make copy of template content
        const root = template.content.cloneNode(true);
        
        // create proxy object for accessing named nodes and root
        const obj = {
                get $root() {
                        // after template root is called, remove this getter function
                        delete obj.$root;
                        
                        // return root only once
                        return(root);
                }
        };
        
        // find all named template nodes and add to proxy object
        for (const node of root.querySelectorAll('[data-tmpl-name]'))
                obj[node.dataset.tmplName] = node;
                
        // otherwise create template node content wrapped in proxy which
        // makes attempts to overwrite properties an error.
        return(new Proxy(obj, {
                set: () => { throw (new Error(`Attempt to overwrite a template node!`)); }
        }));
    }
    

You can use it with something like:

    <template id="some_id">
        <div>
            <h3 data-tmpl-name="header"></h3>
            <h5 data-tmpl-name="title"></h5>
        </div>
        <p data-tmpl-name="info"></p>
    </template>

And then just:

    function of_some_sort() {
        const t = $template(document.getElementById('some_id'));
        
        t.header.innerHTML = 'The Header';
        t.title.innerHTML = 'The title';
        
        t.info.innerHTML = 'More stuff.';
        
        document.body.append(t.$root);
    }
    

This is was the first version I made. It's not hard to get from here to a version that can fill the template with a data object for you. In my most recent version, you could do:

    function of_another_sort() {
        document.body.append($template(document.getElementById('some_id'), {
            header: 'The Header',
            title:  ['first title', 'second title'],
            
            info: (elem) => {
                elem.setAttribute('functions', 'work');
                elem.innerHTML = 'and receive the internal element itself.';
            }
        }));
    }
    

Arrays duplicate the internal element and make copies of it, objects recurse into the element building a 'key.path.name' while looking for data-tmpl-name to replace. Functions get a copy of the element for more than just innerText/innerHTML replacement. A null or false value eliminates the internal element, and a true value passes it through unchanged.

If you've ever used the old ruby library Amrita, it's basically that, but for HTML Template elements. You can easily do all this in about 100 lines of JS.

This approach always seems so easy at first glance, but I find it gets rather unwieldy as soon as I need to update some deeply nested value- like updating a innerText in cell in a table in a card in a layout of a thousand cards without re-rendering the entire collection. I started using lit-html and it solves this problem (and only costs me 3KB or so to ship).

I've used this approach in my minimal MVC lib for over a decade, simply using hidden elements instead of templates

http://krymski.com/espresso.js/

Is the demo site still supposed to be up? I see

> TypeError: path must be absolute or specify root to res.sendFile

when I try to visit it.

That's what the `<template>` element does. From the HTML standard[0]:

> The template element can have template contents, but such template contents are not children of the template element itself. Instead, they are stored in a DocumentFragment associated with a different Document — without a browsing context — so as to avoid the template contents interfering with the main Document.

[0]: https://html.spec.whatwg.org/multipage/syntax.html#template-...

i remember doing stuff like that too, but now it's official! ha.

it's exciting to see web standards (finally) taking direction from web developers rather than corporate interests, despite chrome being so prominent. as a random aside, i'm especially hoping forms get more love, like the common behaviors (datetime entry, combobox, validation/feedback, etc.) that every developer has to wrangle with over and over. and it's great to see things like the <modal> element becoming almost fully usable without js (it still needs to be triggered via js, but can be closed with a method='dialog' form button).

You weren't doing the same thing, though it may have had the same effect. Template elements aren't part of the "main" DOM.

And if you want it to be a valid HTML custom-element, just throw a dash in the name (like <v-foo>). https://html.spec.whatwg.org/#valid-custom-element-name

With templates, you can do things like template.querySelector("label").

template does HTML parsing. The `content` attribute returns a DocumentFragment.