One of the more interesting developments coming out of the Word Wide Web Consortium’s standards process is the group of technologies that power Web components.
Designed to help developers produce reusable elements that can help simplify Web page design and development, they’re the underpinnings of design tools like Google’s Polymer. But what goes into making a Web component, and what will you need to think about if you’re building your own tooling?
Web components, as they currently stand, are actually a mix of several different HTML5 technologies. Some handle interactions with a page’s DOM, while others handle inserting code into page content. Not all of them are supported by all browsers, either. You’ll find Chrome and Firefox offer the best support, with Microsoft’s Edge currently starting to implement some key features. That doesn’t mean you can’t use them -- as with Google’s Polymer components, you can use a polyfill to add support for most of Web components' main features.
At the heart of Web components is the idea of custom elements, as shown by Google’s Polymer. The W3C defines Web components as providing “a way for Web developers to build their own, fully featured DOM elements.” It’s an important concept because it allows for the Web to be customized easily without affecting the underlying technologies that power our browsers. That means it also provides a mechanism for experimenting with new tags, as well as a way of bringing associated technologies (like SVG and MathML) into a common framework.
A custom element looks like any existing HTML element to a designer or a developer. That means it needs to obey the rules of the HTML namespace, and while it must contain a hyphen, it can’t overwrite the existing hyphenated elements already in use on the Web. New elements must be attached to a document’s registry, along with its interface definition. If there’s no registry in a document, then a custom element will be ignored.
The result is an encapsulation of all the code that makes up a user interface element in a page as a single custom tag, much like a browser implementing the <video> tag. With a complex tag, a browser handles displaying all the controls needed to play a video, as well as loading the video itself. A well-defined Web component behaves much the same, handling all the user interface features needed to, say, implement a scrolling list box.
Under your browser's hood is a separate, shadow DOM. Like the DOM that renders your page, a browser renders the elements used to build its own UI. What Web components do is open up that shadow DOM to your code, working with it to render the elements in a Web component template.
Templates are an important part of the Web component model. They’re where you define the structure of a new element, handling its layout on the page. Once given a name, a template can be called by JavaScript code and can be styled by its own (or an externally applied) CSS. Using the shadow DOM, a custom element can be styled without its styles affecting the rest of the document. That means you can build, for example, a slideshow element that can be used by a CMS to render several images and related text.
You can take a template, make it a custom element, then call its createShadowRoot method to create a section of a page with its own DOM. You can then use familiar JavaScript techniques to work with your shadow DOM content, programmatically adding HTML and CSS code. All a user will see (apart from the content rendered by the shadow DOM) is the shadow root, which is tied to a custom element.
One important feature of the shadow DOM is what’s known as the shadow barrier. If, for example, all the <h1> tags in a shadow DOM are styled to be Helvetica in blue, and you apply a style to the entire document to set <h1> tags as Comic Sans in red, none of the content in the shadow DOM block will be styled with the external style -- it will remain as blue Helvetica. It’s a feature that means your predefined blocks will remain the way you’ve defined them.
The final piece of the Web component jigsaw is HTML Imports. Perhaps the most controversial of the four building blocks, it’s unlikely to be fully supported by all browsers. Intended to package HTML content (including Web components) for inclusion in other documents, it’s an alternative to the complexities and security risks of the iframe and of using AJAX to drop HTML content into your code.
Starting with an import link in a document, content is loaded from a directory on your server or from a trusted location on another domain. While you’ll likely have import locations in all your documents to handle deep-linking, there’s no need to worry about excessive network traffic: A file is loaded only once and cached by the browser, with subsequent calls to the import ignored. You’re likely to use imports to handle custom elements and templates, but they’re also suitable for loading large JavaScript libraries using a single import definition to load all the files needed to run your code.
Web components might look like a tool for building a more customizable Web, but that’s not the case. Anything you can do in Web components you can do in HTML 5. What Web components deliver is a set of tools for a more reusable, more repeatable Web.
With Web components, you can design and test a set of UI elements or controls once, then package them for use on other sites or services. There’s even the possibility of being able to sell elements of functionality as add-ons for cloud services that can be plugged into your customers' sites.