Introduction

The concept of templating is not new to web development. In fact, server-side templating languages/engines like Django (Python), ERB/Haml (Ruby), and Smarty (PHP) have been around for a long time. In the last couple of years however, we've seen an explosion of MVC frameworks spring up. All of them are slightly different, yet most share a common mechanic for rendering their presentational layer (aka da view): templates.

They're a place to put a big wad of HTML that you don't want the browser to mess with at all...for any reason.
Rafael Weinstein (spec author)

Feature Detection

To feature detect , create the DOM element and check that the .content property exists:

function supportsTemplate(){return'content'in document.createElement('template');}if(supportsTemplate()){// Good to go!}else{// Use old templating techniques or libraries.}

Declaring template content

The HTML element represents a template in your markup. It contains "template contents"; essentially inert chunks of cloneable DOM. Think of templates as pieces of scaffolding that you can use (and reuse) throughout the lifetime of your app.

To create a templated content, declare some markup and wrap it in the element:

The observant reader may notice the empty image. That's perfectly fine and intentional. A broken image won't 404 or produce console errors because it won't be fetched on page load. We can dynamically generate the source URL later on. See
the pillars.

The pillars

Wrapping content in a gives us few important properties.

Its content is effectively inert until activated. Essentially, your markup is hidden DOM and does not render.

Any content within a template won't have side effects. Script doesn't run, images don't load, audio doesn't play,...until the template is used.

Content is considered not to be in the document. Using document.getElementById() or querySelector() in the main page won't return child nodes of a template.

Activating a template

To use a template, you need to activate it. Otherwise its content will never render. The simplest way to do this is by creating a deep copy of its .content using Closed On Mid Pull Heels Low AmoonyFashion Top Boots Frosted Women's Round Toe Gray document.importNode(). The .content property is a read-only DocumentFragment containing the guts of the template.

The problem with this approach is that the more complex your Shadow DOM gets, the more string concatenation you're doing. It doesn't scale, things get messy fast, and babies start to cry. This approach is also how XSS was born in the first place! to the rescue.

Something more sane would be to work with DOM directly by appending template content to a shadow root:

There's no way to "prerender" a template, meaning you cannot preload assets, process JS, download initial CSS, etc. That goes for both server and client. The only time a template renders is when it goes live.

Be careful with nested templates. They don't behave as you might expect. For example:

Activating the outer template will not active inner templates. That is to say, nested templates require that their children also be manually activated.

The road to a standard

Let's not forget where we came from. The road to standards-based HTML templates has been a long one. Over the years, we've come up with some pretty clever tricks for creating reusable templates. Below are two common ones that I've come across. I'm including them in this article for comparison.

Method 1: Offscreen DOM

One approach people have been using for a long time is to create "offscreen" DOM and hide it from view using the hidden attribute or display:none.

id="mytemplate"hidden>src="logo.png">

class="comment">

While this technique works, there are a number of downsides. The rundown of this technique:

Using DOM - the browser knows DOM. It's good at it. We can easily clone it.

Nothing is rendered - adding hidden prevents the block from showing.

Not inert - even though our content is hidden, a network request is still made for the image.

Painful styling and theming - an embedding page must prefix all of its CSS rules with #mytemplate in order to scope styles down to the template. This is brittle and there are no guarantees we won't encounter future naming collisions. For example, we're hosed if the embedding page already has an element with that id.

Method 2: Overloading script

Another technique is overloading and manipulating its content as a string. John Resig was probably the first to show this back in 2008 with his . Now there are many others, including some new kids on the block like handlebars.js.

Inert - the browser doesn't parse the script content as JS because its type is set to something other than "text/javascript".

Security issues - encourages the use of .innerHTML. Run-time string parsing of user-supplied data can easily lead to XSS vulnerabilities.

Conclusion

Remember when jQuery made working with DOM dead simple? The result was Round AmoonyFashion On Low Heels Boots Closed Toe Gray Pull Top Women's Mid Frosted querySelector()/Pull Closed Women's Toe Boots AmoonyFashion Low Gray Mid Round Frosted Top Heels On querySelectorAll() being added to the platform. Obvious win, right? A library popularized fetching DOM with CSS selectors and standards later adopted it. It doesn't always work that way, but I love when it does.

I think is a similar case. It standardizes the way we do client-side templating, but more importantly, it removes the need for our crazy 2008 hacks. Making the entire web authoring process more sane, more maintainable, and more full featured is always a good thing in my book.