<template> specification was introduced in 2011, along with the other three specs that make up WebComponents. Since then,
<template> has become a part of the W3C Living Document, and has full support in Chrome, Firefox, Opera, Safari, and Android. To boot, Edge has just announced upcoming support.
In light of that announcement, let’s refresh (:
<template> tag was introduced we still had templates, but to get them to work, we had to abuse existing functionality. The two most common techniques were:
- Hide the DOM off screen
- Abusing the
Both of these techniques are not ideal. The first is clunky and can be accidentally modified by DOM manipulation. The latter exposes us to potential cross-site scripting attacks. The
<template> element seeks to solve these issues, and also provides additional benefits.
The Anatomy of a Template
<template> tags. A template can even include another template! Here is a basic example:
The Properties of a Template
This code can live anywhere inside the
<body>. It’s also important to note that you can place it as a child for a
Hidden from CSS and Selectors
Your template’s content cannot be selected or modified with CSS or query selectors. This is to protect it from accidental changes, and for performance reasons.
But.. How do we use our template?
Chiggity-check this out:
Simple enough. We’re:
- Grabbing a reference to our template’s content.
- We create a deep-copy clone of the template’s content
- and then we insert it into our existing DOM.
Simple Template Example
Notice that even though our
span style is defined in our template, it doesn’t affect the existing
span until it is cloned and added. Also, the JS is not executed until the template is added. Even the
<image> isn’t fetched pre-load. Basically, adding the template is like a live copy & paste into your DOM.
Can I data-bind? Data-binding is fun!
Nope. The closest we can get to this is using DOM manipulation techniques to change our templates to create “fake” data-binding. Here is a slightly more intense example that demonstrates this:
- Our template is inside our table
- The template’s row is not visible on the screen
- We grab a reference to the template’s content
- We pull values from our form fields
- We update the template’s content with our values
- We clone the now modified template
- We add the clone to the page
You get the idea. Not super intuitive, but it works. This is likely where we’ll see abstractions like polymer pick up the slack and introduce more developer friendly ways to do data-binding.
Until we get full cross-browser support, it’s fairly safe to rely on Polyfills for
<template> as they’re simple and performant. Here are some examples of polyfill use:
Even so, unless your target browser support is IE11+, you probably shouldn’t be using
<template> in production. If anyone has any sources that show otherwise, please let me know! (:
Templates lay the groundwork for the real meat and potatoes of WebComponents. To fully leverage their power, you may want to check out:
- Continuing your education on the
- Annnddd some more education
- Learning about Custom Elements (hint they use templates)
- Learn more about polyfills
- This article in Markdown format on GitHub
- “Simple Template” Example on GitHub
- “Data-Bind Template” Example on GitHub
<template>s browser support
Questions from this reddit thread and comments below will eventually be aggregated here