A Guide to Web Components

The following is a guest post by Rob Dodson (@rob_dodson). Rob and I were going back and forth in CodePen support getting Polymer (a web components polyfill, kinda) working on a demo of his. We did get it working, and things kind of evolved into this article. Take it away Rob.

Update: Rob updated this article on March 5, 2014, getting everything up to date, as this is a rather fast-moving technology at the moment.

Update: Updating again September 9, 2014!

---

Recently I was working with a client to train their internal teams on how to build web applications. During this process it occurred to me that the way we presently architect the front-end is very strange and even a bit broken. In many instances you’re either copying huge chunks of HTML out of some doc and then pasting that into your app (Bootstrap, Foundation, etc.), or you’re sprinkling the page with jQuery plugins that have to be configured using JavaScript . It puts us in the rather unfortunate position of having to choose between bloated HTML or mysterious HTML, and often we choose both.

In an ideal scenario, the HTML language would be expressive enough to create complex UI widgets and also extensible so that we, the developers, could fill in any gaps with our own tags. Today, this is finally possible through a new set of standards called Web Components.

Web Components?

Web Components are a collection of standards which are working their way through the W3C and landing in browsers as we speak. In a nutshell, they allow us to bundle markup and styles into custom HTML elements. What’s truly amazing about these new elements is that they fully encapsulate all of their HTML and CSS. That means the styles that you write always render as you intended, and your HTML is safe from the prying eyes of external JavaScript.

If you want to play with native Web Components I’d recommend using Chrome, since it has the best support. As of Chrome version 36, it is the first browser to ship all of the new standards.

Le Practical Example

Think about how you currently implement an image slider, it might look something like this:

<div id="slider">
  <input checked="" type="radio" name="slider" id="slide1" selected="false">
  <input type="radio" name="slider" id="slide2" selected="false">
  <input type="radio" name="slider" id="slide3" selected="false">
  <input type="radio" name="slider" id="slide4" selected="false">
  <div id="slides">
    <div id="overflow">
      <div class="inner">
        <img src="images//rock.jpg">
        <img src="images/grooves.jpg">
        <img src="images/arch.jpg">
        <img src="images/sunset.jpg">
      </div>
    </div>
  </div>
  <label for="slide1"></label>
  <label for="slide2"></label>
  <label for="slide3"></label>
  <label for="slide4"></label>
</div>

See the Pen CSS3 Slider by Rob Dodson (@robdodson) on CodePen

Image slider adapted from CSScience. Images courtesy of Eliya Selhub

That’s a decent chunk of HTML, and we haven’t even included the CSS yet! But imagine if we could remove all of that extra cruft and reduce it down to only the important bits. What would that look like?

<img-slider>
  <img src="images/sunset.jpg" alt="a dramatic sunset">
  <img src="images/arch.jpg" alt="a rock arch">
  <img src="images/grooves.jpg" alt="some neat grooves">
  <img src="images/rock.jpg" alt="an interesting rock">
</img-slider>

Not too shabby! We’ve ditched the boilerplate and the only code that’s left is the stuff we care about. This is the kind of thing that Web Components will allow us to do. But before I delve into the specifics I’d like to tell you another story.

Hidden in the shadows

For years the browser makers have had a sneaky trick hidden up their sleeves. Take a look at this <video> tag and really think about all the visual goodies you get with just one line of HTML.

<video src="./foo.webm" controls></video>

There’s a play button, a scrubber, timecodes and a volume slider. Lots of stuff that you didn’t have to write any markup for, it just appeared when you asked for <video>.

But what you’re actually seeing is an illusion. The browser makers needed a way to guarantee that the tags they implemented would always render the same, regardless of any wacky HTML, CSS or JavaScript we might already have on the page. To do this, they created a secret passageway where they could hide their code and keep it out of our hot little hands. They called this secret place: the Shadow DOM.

If you happen to be running Google Chrome you can open your Developer Tools and enable the Show user agent shadow DOM flag. That’ll let you inspect the <video> element in more detail.

Inside you’ll find that there’s a ton of HTML all hidden away. Poke around long enough and you’ll discover the aforementioned play button, volume slider, and various other elements.

Now, think back to our image slider. What if we all had access to the shadow DOM and the ability to declare our own tags like <video>? Then we could actually implement and use our custom <img-slider> tag.

Let’s take a look at how to make this happen, using the first pillar of Web Components, the template.

Templates

Every good construction project has to start with a blueprint, and with Web Components that blueprint comes from the new <template> tag. The template tag allows you to store some markup on the page which you can later clone and reuse. If you’ve worked with libraries like mustache or handlebars before, then the <template> tag should feel familiar.

<template>
  <h1>Hello there!</h1>
  <p>This content is top secret :)</p>
</template>

Everything inside a template is considered inert by the browser. This means tags with external sources—<img>, <audio>, <video>, etc.—do not make http requests and <script> tags do not execute. It also means that nothing from within the template is rendered on the page until we activate it using JavaScript.

So the first step in creating our <img-slider> is to put all of its HTML and CSS into a <template>.

See the Pen CSS3 Slider Template by Rob Dodson (@robdodson) on CodePen

Once we’ve done this, we’re ready to move it into the shadow DOM.

Shadow DOM

To really make sure that our HTML and CSS doesn’t adversely affect the consumer we sometimes resort to iframes. They do the trick, but you wouldn’t want to build your entire application in ’em.

Shadow DOM gives us the best features of iframes, style and markup encapsulation, without nearly as much bloat.

To create shadow DOM, select an element and call its createShadowRoot method. This will return a document fragment which you can then fill with content.

<div class="container"></div>

<script>
  var host = document.querySelector('.container');
  var root = host.createShadowRoot();
  root.innerHTML = '<p>How <em>you</em> doin?</p>'
</script>

Shadow Host

In shadow DOM parlance, the element that you call createShadowRoot on is known as the Shadow Host. It’s the only piece visible to the user, and it’s where you would ask the user to supply your element with content.

If you think about our <video> tag from before, the <video> element itself is the shadow host, and the contents are the tags you nest inside of it.

<video>
  <source src="trailer.mp4" type="video/mp4">
  <source src="trailer.webm" type="video/webm">
  <source src="trailer.ogv" type="video/ogg">
</video>

Shadow Root

The document fragment returned by createShadowRoot is known as the Shadow Root. The shadow root, and its descendants, are hidden from the user, but they’re what the browser will actually render when it sees our tag.

In the <video> example, the play button, scrubber, timecode, etc. are all descendants of the shadow root. They show up on the screen but their markup is not visible to the user.

Shadow Boundary

Any HTML and CSS inside of the shadow root is protected from the parent document by an invisible barrier called the Shadow Boundary. The shadow boundary prevents CSS in the parent document from bleeding into the shadow DOM, and it also prevents external JavaScript from traversing into the shadow root.

Translation: Let’s say you have a style tag in the shadow DOM that specifies all h3’s should have a color of red. Meanwhile, in the parent document, you have a style that specifies h3’s should have a color of blue. In this instance, h3’s appearing within the shadow DOM will be red, and h3’s outside of the shadow DOM will be blue. The two styles will happily ignore each other thanks to our friend, the shadow boundary.

And if, at some point, the parent document goes looking for h3’s with $('h3'), the shadow boundary will prevent any exploration into the shadow root and the selection will only return h3’s that are external to the shadow DOM.

This level of privacy is something that we’ve dreamed about and worked around for years. To say that it will change the way we build web applications is a total understatement.

Shadowy Sliders

To get our img-slider into the shadow DOM we’ll need to create a shadow host and populate it with the contents of our template.

<template>
  <!-- Full of slider awesomeness -->
</template>

<div class="img-slider"></div>

<script>
  // Add the template to the Shadow DOM
  var tmpl = document.querySelector('template');
  var host = document.querySelector('.img-slider');
  var root = host.createShadowRoot();
  root.appendChild(document.importNode(tmpl.content, true));
</script>

In this instance we’ve created a div and given it the class img-slider so it can act as our shadow host.

We select the template and do a deep copy of its internals with document.importNode. These internals are then appended to our newly created shadow root.

If you’re using Chrome you can actually see this working in the following pen.

See the Pen CSS3 Slider Shadow DOM by Rob Dodson (@robdodson) on CodePen

Insertion Points

At this point our img-slider is inside the shadow DOM but the image paths are hard coded. Just like the <source> tags nested inside of <video>, we’d like the images to come from the user, so we’ll have to invite them over from the shadow host.

To pull items into the shadow DOM we use the new <content> tag. The <content> tag uses CSS selectors to cherry-pick elements from the shadow host and project them into the shadow DOM. These projections are known as insertion points.

We’ll make it easy on ourselves and assume that the slider only contains images, that way we can create an insertion point using the img selector.

<template>
  ...
  <div class="inner">
    <content select="img"></content>
  </div>
</template>

Because we are projecting content into the Shadow DOM using an insertion point, we’ll also need to use the new ::content pseudo-element to update our CSS.

#slides ::content img {
  width: 25%;
  float: left;
}

If you want to know more about the new CSS selectors and combinators added by Shadow DOM, take a look at this cheat sheet I threw together.

Now we’re ready to populate our img-slider.

<div class="img-slider">
  <img src="images/rock.jpg" alt="an interesting rock">
  <img src="images/grooves.jpg" alt="some neat grooves">
  <img src="images/arch.jpg" alt="a rock arch">
  <img src="images/sunset.jpg" alt="a dramatic sunset">
</div>

This is really cool! We’ve cut the amount of markup that the user sees way down. But why stop here? We can take things a step further and turn this img-slider into its own tag.

Custom Elements

Creating your own HTML element might sound intimidating but it’s actually quite easy. In Web Components speak, this new element is a Custom Element, and the only two requirements are that its name must contain a dash, and its prototype must extend HTMLElement.

Let’s take a look at how that might work.

<template>
  <!-- Full of image slider awesomeness -->
</template>

<script>
  // Grab our template full of slider markup and styles
  var tmpl = document.querySelector('template');

  // Create a prototype for a new element that extends HTMLElement
  var ImgSliderProto = Object.create(HTMLElement.prototype);

  // Setup our Shadow DOM and clone the template
  ImgSliderProto.createdCallback = function() {
    var root = this.createShadowRoot();
    root.appendChild(document.importNode(tmpl.content, true));
  };

  // Register our new element
  var ImgSlider = document.registerElement('img-slider', {
    prototype: ImgSliderProto
  });
</script>

The Object.create method returns a new prototype which extends HTMLElement. When the parser finds our tag in the document it will check to see if it has a method named createdCallback. If it finds this method it will run it immediately. This is a good place to do setup work, so we create some Shadow DOM and clone our template into it.

We pass the tag name and prototype to a new method on the document, called registerElement, and after that we’re ready to go.

Now that our element is registered there are a few different ways to use it. The first, and most straightforward, is to just use the <img-slider> tag somewhere in our HTML. But we can also call document.createElement("img-slider") or we can use the constructor that was returned by document.registerElement and stored in the ImgSlider variable. It’s up to you which style you prefer.

Support

Support for the various standards that makeup Web Components is encouraging, and improving all the time. This table illustrates where we’re presently at.

But don’t let the lack of support in some browsers discourage you from using them! The smarties at Mozilla and Google have been hard at work building polyfill libraries which sneak support for Web Components into **all modern browsers**! This means you can start playing with these technologies today and give feedback to the folks writing the specs. That feedback is important so we don’t end up with stinky, hard to use syntax.

Let’s look at how we could rewrite our img-slider using Google’s Web Component library, Polymer.

Polymer to the Rescue!

Polymer adds a new tag to the browser, <polymer-element>, which automagically turns templates into shadow DOM and registers custom elements for us. All we need to do is to tell Polymer what name to use for the tag and to make sure we include our template markup.

See the Pen Polymer Slider by Chris Coyier (@chriscoyier) on CodePen.

I find it’s often easier to create elements using Polymer because of all the niceties built into the library. This includes two-way binding between elements and models, automatic node finding and support for other new standards like Web Animations. Also, the developers on the polymer-dev mailing list are extremely active and helpful, which is great when you’re first learning the ropes, and the StackOverflow community is growing.

This is just a tiny example of what Polymer can do, so be sure to visit its project page and also checkout Mozilla’s alternative, X-Tag.

Issues

Any new standard can be controversial and in the case of Web Components it seems that they are especially polarizing. Before we wrap up, I want to open up for discussion some of the feedback I’ve heard over the past few months and give my take on it.

OMG it’s XML!!!

I think the thing that probably scares most developers when they first see Custom Elements is the notion that it will turn the document into one big pile of XML, where everything on the page has some bespoke tag name and, in this fashion, we’ll make the web pretty much unreadable. That’s a valid argument so I decided to kick the bees’ nest and bring it up on the Polymer mailing list.

The back and forth discussion is pretty interesting but I think the general consensus is that we’re just going to have to experiment to see what works and what doesn’t. Is it better, and more semantic, to see a tag name like <img-slider> or is our present “div soup” the only way it should be? Alex Rusell composed a very thoughtful post on this subject and I’d recommend everyone take the time to read it before making up their mind.

SEO

At this moment it’s unclear how well crawlers support Custom Elements and Shadow DOM. The Polymer FAQ states:

Search engines have been dealing with heavy AJAX based application for some time now. Moving away from JS and being more declarative is a good thing and will generally make things better.

The Google Webmaster’s blog recently announced that the Google crawler will execute JavaScript on your page before indexing it. And using a tool like Fetch as Google will allow you to see what the crawler sees as it parses your site. A good example is the Polymer website, which is built with custom elements and is easily searched in Google.

One tip I’ve learned from speaking with members of the Polymer team is to try to make sure the content inside of your custom element is static, and not coming from a data binding.

<!-- probably good -->
<x-foo>
  Here is some interesting, and searchable content...
</x-foo>

<!-- probably bad -->
<x-foo>
  {{crazyDynamicContent}}
</x-foo>

<!-- also probably bad -->
<a href="{{aDynamicLink}}">Click here</a>

To be fair, this isn’t a new problem. AJAX heavy sites have been dealing with this issue for a few years now and thankfully there are solutions out there.

Accessibility

Obviously when you’re hiding markup in secret shadow DOM sandboxes the issue of accessibility becomes pretty important. Steve Faulkner took a look at accessibility in shadow DOM and seemed to be satisfied with what he found.

Results from initial testing indicate that inclusion of ARIA roles, states and properties in content wholly inside the Shadow DOM works fine. The accessibility information is exposed correctly via the accessibility API. Screen readers can access content in the Shadow DOM without issue.

The full post is available here.

Marcy Sutton* has also written a post exploring this topic in which she explains:

Web Components, including Shadow DOM, are accessible because assistive technologies encounter pages as rendered, meaning the entire document is read as “one happy tree”.

*Marcy also points out that the img-slider I built in this post is not accessible because our css label trick makes it inaccessible from the keyboard. Keep that in mind if you’re looking to reuse it in a project.

Surely there will be bumps along the way but that sounds like a pretty great start!

Style tags? Um, no thanks.

Unfortunately <link> tags do not work inside of the Shadow DOM, which means the only way to pull in external CSS is through @import. In other words, <style> tags are—for the moment—unavoidable.*

Keep in mind that the styles we’re talking about are relevant only to a component, whereas we’ve previously been trained to favor external files because they often affect our entire application. So is it such a bad thing to put a <style> tag inside of an element, if all of those styles are scoped just to that one entity? Personally I think it’s OK, but the option of external files would be very nice to have.

* Unless you use Polymer which gets around this limitation with XHR.

Now it’s your turn

It’s up to us to figure out where these standards should go and what best practices will guide them. Give Polymer a shot, and also look at Mozilla’s alternative to Polymer, X-Tag (which has support all the way down to Internet Explorer 9).

Also, make sure you reach out to the developers at Google and Mozilla who are driving the bus on these standards. It’ll take our feedback to properly mold these tools into something we all want to use.

While there are still some rough edges, I think Web Components will eventually usher in a new style of application development, something more akin to snapping together Legos and less like our current approach, which is often plagued by excess boilerplate. I’m pretty excited by where all of this is heading, and I look forward to what the future might hold.