Web components let you extend HTML with new capabilities so you can write better web apps faster. Component Kitchen is the place to learn about web components, and to find components developed by the web community for use in your projects. You can start with our web component tutorial, browse our comprehensive catalog of public web components, or read our Staff Reviews and other component news below.
For the last few months, we've been excited to help a new open project get off the ground: the Gold Standard checklist for web components. The checklist’s goal is to define a consistent, high quality bar for web components.
We believe web components should be every bit as predictable, flexible, reliable, and useful as standard HTML elements. When someone is working in HTML, they should be able to work as if all elements work the same. They shouldn’t need to learn a special set of constraints or limitations that apply to specific custom elements. They already know how standard HTML elements behave; new custom elements should behave just like that.
The standard HTML elements establish an incredibly high bar for quality. For example, you can use the standard elements in any combination, and they’ll not only work, the result is usually predictable and reasonable. But, without a great deal of care, custom elements don’t support that same degree of flexibility by default. It’s all too easy to create a custom element that only works when it’s used in a very particular way.
The project began by defining what it is that makes a standard HTML element feel like a standard HTML element. It seems no one before ever wrote down all the criteria that govern the expected behavior of a new standard HTML element. We all generally know how HTML elements should behave, and through careful design and testing, new standard elements eventually measure up to our expectations.
You can think of this as a Turing Test for elements: if you were to encounter an unfamiliar element in HTML, could you tell whether it was a new standard element or a custom element? For most custom elements today, it wouldn’t take too long to discover some unexpected quirk or limitation in the element that would reveal its custom element nature. This is not for lack of dedication on the component author’s part. It could simply be the case that they hadn’t considered some aspect of standard element behavior.
To address that, the Gold Standard checklist captures the expected behavior of a standard HTML element in a form that can guide the creation of new custom elements. The checklist covers a wide range of topics, from accessibility to performance to visual presentation. A component that meets that quality bar should be able to generally satisfy all the expectations of people using that component. This will greatly facilitating the component’s adoption and use.
A variety of people, particularly from Google, have already contributed to the Gold Standard checklist in its draft stages, and continue to make contributions to the checklist in its new wiki form. The initial focus of the project has been to develop a solid set of top-level checklist items. It’s the hope of the project contributors that every item on the list will be backed by a detailed explanation of the checklist item: why it’s important, examples of what to do or not to do, sample source code, and other resources.
If you’re interested in creating or using high-quality components, please take a look at the checklist. The project welcomes comments and suggestions as issues, or direct contributions through pull requests.
We've just posted an interactive web components tutorial that teaches the basic concepts with editable live demos. We hope you'll find that this tutorial:
Please check it out, share it, and let us know what you think!
If you hold or participate in project management discussions, consider printing out this handy Printable Wall Calendar that was quickly built with web components.
Jan constructed the original version of this calendar years ago to answer to two simple calendar questions that often come up in planning discussions:
You can answer these questions by pulling out your phone, but sometimes paper is faster than gadgets. A wall calendar can answer these questions nearly instantly — as long as the calendar is well designed for this purpose. The problem is that most wall calendars have way too much clutter. They're designed for a previous era in which people wrote critical scheduling information on a paper wall calendar. No one does that now. If instead you just want a calendar to answer the questions above, its design can be much simpler. A simpler design means the actual calendar dates can be bigger and easier to read across a room.
This calendar was built using the basic-calendar-month component, which takes care of all the date math, as well as handling localized month and day names for a huge number of languages and regional preferences. To build a year calendar was a simple matter of slapping 12 of these month calendars together and applying some styling.
This review focuses not on a component, but an aspect of a component called basic-list-box. Component Kitchen released that component under the aegis of the Basic Web Components project. In our reviews, we want to avoid focusing too much on our own work, but in this case we can happily feature a small but important contribution to the project from developer Marcy Sutton, a passionate advocate for building an accessible web that can be used by everyone.
An important goal for Basic Web Components is to make all its components as accessible as possible, for several reasons. You can use these components, used as is, and reach the broadest possible range of users. You can extend these components or incorporate them into your own components, and automatically pick up a degree of support for accessibility. And you can refer to these components as good examples of how to implement accessibility if you’re creating a new component entirely from scratch. This work is just beginning, and by no means perfect, but those are the goals. The good news is that improvements are made to the components, anyone using those components can easily pick up those improvements for free.
As a case in point, Marcy recently contributed an enhancement to basic-list-box (and a lower-level base class called basic-selector) that improves a list's accessibility through the use of appropriate ARIA features on the list itself and the individual items in the list. The best part about an improvement like this in a fundamental building block like basic-selector or basic-list-box means that you can achieve better accessibility simply by using those components. Even if you know nothing about ARIA and accessibility technologies, using these components makes your app likely to be more accessible than one constructed from a undifferentiated pile of divs.
Noteworthy: Support for keyboard navigation, including Up/Down, Page Up/Down, Home/End. Appropriate use of ARIA roles and other attributes means that users who are blind or visually impaired can more easily identify and navigate a list of items.
Nits: The component only works with <article> elements (or elements with role="article"); it would be nicer if it could work with any type of child element. The component also moves all the children from the light DOM (the outer page) to the component's own shadow DOM. This effectively removes the children from the main page, complicating styling and the handling of events generated by the children.
Apologies that we were unable to get our demo working in IE. We try hard to ensure all demos work in all mainstream browsers, but after spending too much time wrestling with IE, we decided we'd rather publish this review than keep debugging. Our issue likely had more to do with our own blog-with-demos environment than with the ordered-columns component itself.
We love the elegant demos and documentation filaraujo is creating for his collection of web components. His akyral-modal component, for example, addresses the common need to have a modal dialog or other UI appear in front of other elements on the page. Several other modal components exist, but none so nicely documented.
Likes: The author's taken care to give akyral-modal a bare-bones appearance. We find often it easier to add our own visual style to a plain component than to try to override a complex visual styling baked into a component's default appearance. We're also a big fan of interactive demos that can be configured on the fly. A demo is worth 10,000 words.
Sometimes the simplest approach works best. A number of registered web components aim to handle the simple task of showing or soliciting a star rating from a user using the now-convential set of 5 stars. On its own, a 5-star rating system can present serious issues, as users tend to offer responses only at the extremes, but when managed well (adding users to add comments to explain their response, etc.), such rating systems can be useful.
We tried three star rating components:
Obviously, with any head-to-head comparison like this, it's hard to say which component is really "best" for everyone. But for our quick experiment, we found x-rating did the job simply and well, so that's the component we're showing in the accompanying demo. Nice work, hershmire!
The voice-elements component gives you easy access to the Web Speech API natively supported (as of this writing) only in Chrome. This lets you both read text aloud to the user, and perform basic voice recognition. Users can quickly tire of repetitive spoken prompts, but voice playback might useful for short alerts that incorporate dynamic content such as data coming from your app.
Likes: This supports multiple accents!
Dislikes: None of the other browsers — Firefox, Safari, and IE — currently support the Web Speech API. We still think components like this are an important indication of the sort of power that components can put in anyone's hand.
We've been eagerly tracking the state of the web components community since we started Component Kitchen earlier this year. Over that time, it's been exciting to watch the number of web components registered with Bower grow from about 40 to nearly 500 today.
The growth in our component catalog, however, has meant that it's becoming harder and harder for someone like you to find interesting components just by browsing around. We want to help you find the interesting stuff. To do that, we're making three changes to our site:
We've begun dedicating a portion of our own time to sifting through the catalog of web components for components that are notable in some way. We want to highlight components that: solve a common user interface design problem in a way that can be readily adopted in your own apps, demonstrate how to write good web components, or show off what's possible with web components.
When we find a notable component, we'll write a small capsule review for it. Along with the review, we’ll craft our own little demo of that component being used in some common way. This demo will let us confirm to ourselves that the component works as advertised, and will also give us a feel for the component’s strengths and weaknesses. We hope these little demos will make it easier for you to see on a small scale what a component might do for you.
We've redesigned our home page to feature these component reviews and other news (like this post). The home page previously featured a complete list of all registered components; that list is now available in the Component Catalog section of our site.
We've moved our temporary Component Kitchen blog feed in house. To get off the ground, we'd hosted our blog on a separate site, but you'll now find it here. If you'd like to keep track of what's happening in the world of web components, subscribe to our blog feed at this new location.
We'll be scouring the catalog of components for interesting work, but if you've seen something you think is worth highlighting, please give us a shout at @ComponentK!
There are already a number of web components that wrap existing slide-based presentation libraries; slide-page is notable for being written from the ground up with web components. The source code for the core component is little more than a wiring together of existing parts in a novel combination. That approach is, in fact, exactly right, and component writing at its best! This component mostly adds sequential arrow button navigation around Polymer's core-animated-pages component. For the buttons, it takes advantage of Google's Material Design theme, specifically the Paper floating action button.
Likes: Great use of existing Polymer and Paper components; some keyboard navigation.
Dislikes: The stock appearance shows a "Powered by Polymer" banner that few people are going to want. It's possible to turn it off through styling, but we like components whose default appearance is the most practical starting point.