Web components let you extend HTML with new capabilities so you can write better web apps faster. Component Kitchen are experts on this transformational technology. We design and develop web components, we work with a range of industry players to improve the underlying specs and libraries, and we consult with companies who want to use web components to make their products better.

An evaluation of polymer-micro as a minimal web component framework

Mon Nov 02 2015 17:00:00 GMT+0000 (UTC)

Our Basic Web Components project currently creates its components using Google's Polymer framework, but we've been evaluating the use of the smaller polymer-micro core as a replacement for full Polymer. The polymer-micro core appears to be a useful web component framework in its own right, and may provide nearly everything a component library like ours needs.

Is Polymer the best choice for our open project?

We believe that some amount of framework is necessary to create web components. For a very long time, Polymer has been the primary web component framework. We love Polymer! However, we feel that Polymer has grown to the point where writing a Polymer app feels distinctly different from writing a typical HTML app.

Polymer provides numerous helpers that reduce the amount of copy-and-paste boilerplate code required to invoke standard DOM features. In current parlance, it wants to make component code as DRY as possible. For example, Polymer provides a "listeners" key for wiring up event handlers with less code than a direct invocation of the underlying addEventListener(). Polymer's "properties" key similarly simplifies definition of component properties instead of directly defining property getter/setters on the component prototype and marshalling attributes to properties with attributeChanged().

We think Polymer's goal is commendable. If you can afford to train up a team of developers on Polymer's specific way of doing things, your team should be able to crank out web UI code very efficiently.

But as with any higher-level abstraction, these helpers trade off clarity and simplicity for a certain degree of magic and complexity. Each reduction in the amount of component code a developer must write forces an increase in the arcane Polymer-specific knowledge a developer must acquire to write or even read component code. It also hides details that may complicate debugging and maintenance.

For our open source project, those second-order effects reduce the potential pool of project contributors. Our priority is not time-to-market, but rather creating code which is self-evident to our open source users and potential contributors. Although 1 line of Polymer code might do the work of 3 lines of standard web code, if those 3 lines are more understandable to a wider base of developers, we might prefer the longer, clearer version.

Carrying forward the burden of backward compatibility

Another issue we're grappling with is Polymer is very much designed for this era immediately before web components emerge with native support across all mainstream browsers. Polymer wants, quite reasonably, to accommodate browsers that don't yet support web components. At the same time, Polymer also wants to deliver decent performance, notably on Mobile Safari, which at this time does not support native Shadow DOM. Rather than use the full Shadow DOM polyfill, Polymer introduced its own Shady DOM approach for approximating Shadow DOM behavior on older browsers.

Shady DOM is an impressive technical accomplishment. But having written a great deal of Shady DOM code this year, it's our subjective opinion that Shady DOM code feels clunky. Even after months of writing Shady DOM code, wrapping DOM calls with Polymer.dom() still doesn't feel natural. And it's hard to explain to someone why they can't just call appendChild(), but have to call Polymer.dom().appendChild() instead. And while Polymer.dom() is somewhat future-proof, it doesn't feel future-facing. It erodes the original, extremely elegant vision for Polymer and the web components polyfills: to let people to write web components for future web browsers today.

The alternative to Shady DOM today is to use the full Shadow DOM polyfill. That entails slower performance and — given inevitable leaks in the abstraction — a greater potential for mysterious bugs. On the plus side, the full Shadow DOM polyfill lets one write clearer, future-facing code. With all the major browser vendors on board with Shadow DOM v1, the need to download and use the Shadow DOM polyfill on most devices should fade over the course of 2016.

We're also excited about the advent of ES6, with features like arrow functions that let code be more concise. Writing an addEventListener() call is no longer a substantial burden in ES6, or at least not enough to warrant a parallel system for event listener wiring. And using built-in ES6 classes feels better than calling a purpose-focused class factory like Polymer().

Considering polymer-micro instead of full Polymer

It turns out that, underneath all of Polymer's DRY magic, there's a very clean, simple core called polymer-micro. Polymer is helpfully constructed in three layers: full Polymer on top, a smaller polymer-mini below that, then a tiny polymer-micro at the bottom. The documentation describes polymer-micro as "bare-minimum Custom Element sugaring".

Rather than use the full Polymer framework, we've been investigating whether polymer-micro on its own could meet our needs. Building on top of polymer-micro confers a number of advantages over writing our own web component framework:

  • Google has already invested an enormous amount of money and resources developing Polymer, including polymer-micro, and will probably continue to do so for the foreseeable future.
  • The thousands of people using full Polymer today are also using polymer-micro. That means lots of testing of the polymer-micro core.
  • From its commit history, polymer-micro looks fairly stable. A substantial amount of future Polymer work will likely happen in the upper levels.
  • In terms of file size, polymer-micro is significantly smaller than full Polymer, although we don't see that as a huge advantage.
  • Relying on a small core like polymer-micro makes it easier to migrate to another framework when a better framework comes along.

The polymer-micro layer happens to provide most of the features upon which Basic Web Components depend:

  • Custom element registration.
  • Lifecycle support.
  • Declared properties.
  • Attribute deserialization to properties.
  • Behaviors.

On the flip side, Basic Web Components use a number of Polymer features which polymer-micro does not provide:

  1. Shadow root Instantiation. If you use polymer-micro, you're expected to create a shadow root yourself.

  2. Templates. If you want to use the <template> element to define initial content of a component's Shadow DOM, you need to manage that yourself.

  3. Shimming for CSS styles. The full Shadow DOM polyfill requires that CSS be transformed to minimize styles leaking across a custom element boundaries. Full Polymer takes care of that for you, but using polymer-micro directly means that style shimming becomes your concern.

  4. Automatic node finding. This lets your component code refer to a sub-element <button id="foo"> with this.$.foo. Complex components need a consistent and easy way to refer to subelements within the local Shadow DOM. Polymer's this.$ syntax satisfies those criteria, although we're really torn as to whether that sugar is worth it. It saves keystrokes, but isn't a web-wide convention. It may give an unfamiliar flavor to web component code.

  5. ready() callback. Many of the Basic Web Components use Polymer's ready callback to initialize themselves. Polymer takes pains to ensure that any Polymer elements inside a component's local Shadow DOM have their own ready callback fired before the outer component's ready callback is fired.

  6. CSS mixins. This is Polymer's current answer for visual themes for components. It's based on a not-yet-standard proposal for extensions to CSS. Without full Polymer, you have to invent your own theming architecture.

All the above features are provided at the levels above polymer-micro: either polymer-mini or full Polymer. However, those upper levels bring along a number of features we don't use, or would be happy to drop. Those features include:

  • Data binding
  • Event listener setup ("listeners" key)
  • Annotated event listener setup (in markup)
  • Property change callbacks
  • Computed properties
  • reflectToAttribute

These features all have some appeal, but in our estimation may add more complexity than they're worth to an open source project aiming for a general developer audience.

Lastly, there are a few higher-level Polymer features we have to use, but wish we didn't have to:

  • <dom-module>. This is used as a wrapper around a <template> element, but it's hard to fathom why <dom-module> is necessary. It seems designed to support a use case we don't care about: defining a template in one file, then using it in a component defined in a separate file. Yet by far the most common way to define a Polymer component is to put its template and script definition in the same file. It's unfortunate full Polymer doesn't offer a better way to use a real <template>directly. (Although a trick does let you accomplish that in an unofficial way; see below.)

  • Polymer.dom(). As noted above, this feels awkward, like you're not using the web. It's also confusing to experienced web developers looking at Polymer code for the first time.

Prototyping a minimal component framework on top of polymer-micro

With the above motivation, we considered the question: What is the smallest amount of code that must be added to polymer-micro to create a web component framework that meets our project's needs?

This experiment entailed a fair amount of spelunking in the Polymer codebase. That exploration informed the creation of a little prototype web component framework called polymer-micro-test that uses only polymer-micro as its base. In this prototype framework, we wrote a small amount of code (minimalComponent.js) to implement the 5 numbered features above which we want but are missing in polymer-micro.

We then used the prototype framework to create a couple of sample components, such as a sample test-element component. A live demo of a simple page shows the test-element component in use. By virtue of using the full polyfills, components created in this prototype framework can run in all mainstream browsers.

Overall, the results of this experiment were fairly positive. Looking at each feature in turn:

  1. Creating a shadow root yourself is easy. This is only necessary for components with templates (next point).

  2. Stamping out a template is easy. The smallest amount of code we could envision for this is for a component to declare a "template" property. This can be used in conjunction with HTML Imports for a fairly clean connection between the script and the template:

    <template id="test-element">
      ... template goes here ...
      is: 'test-element',
      template: currentImport.querySelector('#test-element')

    Aside: we really like being able to use a plain template to define component content. It turns out that you can actually do this in full Polymer today, although it's something of a trick that depends upon your component defining an undocumented _template variable. See this gist, which works in full Polymer.

  3. Shimming CSS styles took a little investigation, but it turns out the full Shadow DOM polyfill exposes its CSS-shimming code as ShadowCSS. The first time this test framework is going to stamp a template, it just invokes ShadowCSS to shim any <style> elements found in the template. It then saves the shimmed result for subsequent stamping into the shadow root.

  4. Automatic node finding. If we conclude we really need this feature, it's not that hard to implement ourselves. Right after the test framework stamps a template, it queries for all the elements in the shadow tree that have an id attribute, then adds those elements to this.$. This gives us a type of automatic node finding that meets our needs. Polymer's own implementation of the same feature is much more complex. It appears to do a lot of tree-parsing so in preparation for data binding, but since we don't need data binding, we don't need to do that work.

  5. The ready() method is a bit of a puzzle to us. The Shadow DOM spec already defines two callbacks, createdCallback() and attachedCallback(), that can cover most of what we're currently doing in ready(). One issue is that createdCallback() and attachedCallback() are synchronous, while the Polymer ready() code takes enormous pains to handle asynchronous calls. That is likely necessary to support their asynchronous data binding model. That is, if your component has a sub-component with data bindings, you want all those asynchronous data bindings to settle down first before your top-level component does its own initialization. Since we're not interested in data binding, however, it's not clear whether we need ready(). Our sample element just uses the standard callbacks.

  6. CSS mixins. This remains an open question for us. It's hard to imagine what we could do to allow component users to theme our components. At the same time, we're not convinced that the not-yet-standard CSS mixins are going to actually become a standard. The troubled history of vendor-prefixed CSS feature experiments suggests that one company's early interpretation of a hypothetical, future CSS mixin "standard" might significantly complicate things down the road when a real standard is finally established.

This small prototype framework delivers most of the features required by Basic Web Components. The main exception is that it offers no facility for component theming (point #6 above).

Some other notes:

  • Because polymer-micro supports Polymer behaviors (mixins), we were able to implement all of the prototype's features in a behavior. That's quite elegant. It means our sample components can use those features simply by calling the standard Polymer() class factory and listing this prototype behavior in the "behaviors" key. It was a nice surprise that we didn't have to create our own component class factory for that.

  • To take advantage of Polymer's own attribute-to-property marshalling feature, we had to invoke an undocumented internal method in polymer-micro. If more people were building directly on top of polymer-micro, such facilities could probably be promoted to supported features.

  • Taking advantage of existing Polymers facilities (both official and undocumented) and polyfill features like ShadowCSS means that our little prototype framework can be tiny, less than 1K in size. That gets added to the size of polymer-micro, which is currently about 15K uncompressed. Combined, that 16K is a lot smaller than the full Polymer, about 105K uncompressed.

  • Any decrease in framework file size is more than offset by the need to use the full web component polyfills, which are much larger than the "lite" version used with Shady DOM. Still, since we think the need for the full polyfills will drop over the course of 2016, we're not particularly concerned about that.


While this is just an experiment, it's intriguing to consider using polymer-micro as the basis for a minimalist web component framework.

  • A minimalist framework leads to component code which we believe is easier for a general web developer to read.

  • Letting a component developer work at a lower level of abstraction — "closer to the metal" — means they have a greater capacity to diagnose problems when things inevitably go wrong. There's less mystery to clear away, so problems can be understood and fixed, rather than worked around.

Despite these advantages, we're not yet ready to say that we're actually going to use this prototype to create components. As noted above, our goal is to foster a codebase that can be readily comprehensible to a wide audience of web developers. Using a proprietary framework, even a tiny one, impedes that goal. (Basic Web Components traces its ancestry to an earlier component library called QuickUI which never gained critical mass, in part because it was built on a proprietary framework.)

Using polymer-micro as the basis for a proprietary framework would be better than writing a framework from scratch, but every bit of code added on top of polymer-micro runs the risk of producing a framework in its own right — one distinct and unfamiliar to our developer audience.

A minimalist strategy like this would only have meaning to us if it's shared by other people. To that end, we've begun talking with other web component organizations to explore this idea a bit further. We're not sure where that discussion will go, but it's interesting, and might bear fruit in the form of a new, minimalist web component framework. If you'd be interested in participating in that discussion, please ping us at @ComponentK.

Nobody writes production web components in vanilla JS — so using a framework makes total sense

Mon Oct 26 2015 16:00:00 GMT+0000 (UTC)

You may hear someone say they avoid using React, Polymer, Angular, or some other framework du jour, and that they prefer to write their front end code in vanilla JavaScript instead. But when it comes to writing web components, it seems everybody ends up writing atop a framework — even if it's a tiny framework of their own devising. Production web components written in vanilla JS appear to be very rare.

It seems there's just a bit too much work involved to meet even baseline expectations for a custom element. To handle instantiation, for example, you might need to:

  1. Create a shadow root on the new instance.

  2. Stamp a template into the shadow root.

  3. Marshall any attributes from the element root to the corresponding component properties. This process breaks down into more work, such as:

    • Loop over the set of attributes on the element.
    • For each attribute, see if the component defines a corresponding property. If you want to support conventionally hyphenated attribute names ("foo-bar"), you'll want to first map those attribute names to conventionally camel-cased property names (fooBar).
    • If the type of a target property is numeric or boolean, parse the string-valued attribute to convert it to a value of the desired type.
    • Set the property to the value.

Given this amount of work to simply instantiate the component, it's easy to see why most efforts to create interesting components typically end up relying on shared code. You might write a single web component in vanilla JS, but as soon as you start your second component, you'll be dying to factor the boilerplate into shared code… And now you're constructing a framework.

That's not necessarily a bad thing. It only means that, when you hear someone say that they want to write a component-based app, but don't want to use any framework at all, you have to take that with a grain of salt. It's possible the person has — perhaps unintentionally — ended up building the foundations of their own web component framework.

Does it matter whether that code is called a framework? Wikipedia enumerates these software framework hallmarks:

  • inversion of control (control flow dictated by the framework, not the code on top of it)
  • default behavior
  • extensibility
  • non-modifiable framework code

Given this definition, it seems hard to conclude that frameworks are bad per se. Surely there are good frameworks as well as bad frameworks.

Perhaps one reason people shy away from the concept of a framework is that, as a framework achieves higher levels of abstraction, it becomes something tantamount to a domain-specific language. If you and I both thoroughly understand JavaScript, but we are using different JavaScript frameworks, then in practice we may not find each other's code mutually intelligible.

Since the term "framework" can provoke strong negative reactions, authors of such code may actually care whether their code is labeled a framework or not. Google, for example, seems to take great pains to avoid describing its own Polymer project as a framework. They call it a "library", which sounds perhaps smaller or less threatening. But Polymer easily meets all of the above framework criteria. For example, Polymer's internal asynchronous task-scheduling infrastructure establishes the flow of control in a Polymer application, determining when to invoke component lifecycle callbacks and property observers.

Whether you like the idea of a framework or not, when it comes to web components, the DOM API is so rudimentary that, in practice, that API alone does not provide a sufficient framework for web component development. As long as that remains the case, the use of a JavaScript web component frameworks seems unavoidable. If you really, really want to avoid writing or using code that meets the above definition of "framework", perhaps you can do so and still be productive, but that seems like a hard way to go.

For our own work, we want to be using a popular web component framework, be it Polymer or something else. If our alternative were to write a proprietary, ad hoc framework of our own, which was shared by no one else, we would likely waste a lot of time solving problems others have already solved.

We’re shutting down our web component catalog

Mon Oct 19 2015 16:00:00 GMT+0000 (UTC)

We launched this Component Kitchen site in April 2014 with a web component catalog as its centerpiece. Today we're shutting down that catalog so we can focus on web component consulting and our open web components projects, including the Gold Standard Checklist for Web Components and the general-purpose Basic Web Components library.

Running the component catalog was a great way to learn about building production applications using web components and Google's Polymer library. But we've come to feel that the catalog's utility is limited, and it no longer makes economic sense to continue it.

  • As in any online space, much of what is freely given publicly is, unfortunately, junk. Many registered components are "Hello, world!", or trivial wrappers of a third-party library, or utilities so specialized as to be useful to no one but their authors. That makes it hard to find something worth using.

  • Even potentially useful components are seldom written at a level of production quality. We tried to start a "component of the week" blog post series in late 2014. We would sift through a dozen components just to find one that even worked outside the narrow confines of its demo. This isn't necessarily the fault of the component authors — it's really hard to write a solid web component today. (That's one reason we believe that establishing a Gold Standard for web component quality is a vital project.) We also believe that the web user interface framework vendors, such as Polymer and X-Tag, need to invest more heavily in making it easy to create components that meet that standard.

  • Our catalog pages showed GitHub stars, but the direct GitHub metadata for projects like web components isn't all that useful in assessing a project's quality. A GitHub star doesn't tell you whether anyone has actually tried a project, whether they thought it was good, whether they used it, or whether they're still using it. We have some ideas for how to compile better indications of a web component project's utility, but they would require a larger investment of our resources than we can afford.

  • People want to see a component project's own documentation, not a third-party repackaging of that documentation. We think that's true for any online catalog, including successful ones like npm. When we find a package on npm, we never read the package details there, because we'll have to go to the actual GitHub repository to form an assessment of whether it's worth actually trying the package.

  • GitHub itself could easily improve its own search and ranking features to the point where external catalogs would struggle to add value. We'd rather not compete with them.

  • As a result of the above points, if you want to find a foobar web component, it's easier to google for "foobar web component" than to consult a purpose-built catalog. If you follow the search results to GitHub, you'll end up where you wanted to go anyway.

  • It turns out that a coherent collection of components designed and implemented together is more interesting than individual components from multiple authors. While we had plans to feature component collections, we didn't think the payoff would be high enough. Again, the collection creator is more interested in driving traffic to their collection's own site, and that's probably what the component customer is interested in seeing too.

Retiring the catalog lets us invest more time in the projects that we think matter more. People who want a component catalog can use customelements.io, which has seen many improvements lately. Also, as a service to people who have made deep links to our catalog's component pages, for the indefinite future we will continue to serve up tombstone pages at those URLs that offer a link to the corresponding repository on GitHub.

When we started our catalog, there were only about 40 publicly registered web components — now the number is in the thousands. We really appreciate all of the people who visited our catalog in the last year and a half, who built a great component we could feature, and who took the time to give us feedback or a shout-out on social sites. We're still excited to be working in this transformative web components space, and look forward to sharing our ongoing work here soon.

The Gold Standard checklist for web components

Wed May 27 2015 16:00:00 GMT+0000 (UTC)

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.

Try our interactive web components tutorial

Mon Jan 12 2015 16:00:00 GMT+0000 (UTC)

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:

  • Explains the key principles at a quick pace under your control.
  • Illustrates the principles through engaging, live HTML demos. We think the best way to learn a technology is to play with it yourself!
  • Introduces concepts from the perspective of the component user. Most web component presentations start with the assumption that you're a developer creating a component from scratch. But one of the great things about web components is that components can be used by a wider audience than the people who can create components.
  • Only requires knowledge of HTML. If you're one of the many people who has read or written HTML, but don't consider yourself to be a developer, this is the tutorial for you. And if you are a developer, we still think this presents the concepts in an approchable and useful manner.

Please check it out, share it, and let us know what you think!

Print a handy 2015 wall calendar built with web components

Sun Dec 21 2014 16:00:00 GMT+0000 (UTC)

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:

  1. On which day of the week will a given date fall? If some asks, "Can you ship this on June 15?", you often want to know, "Well, what day of the week is that? Is that even a weekday?"
  2. What's the date of a given day of the week? Maybe your agile development group likes to make big releases on Mondays. If you think you might release something two Mondays from now, what date is that?

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.

basic-list-box — keyboard-navigable list box, now with ARIA support for better accessibility

Wed Dec 10 2014 16:00:00 GMT+0000 (UTC)

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.

See our full details on basic-list-box

ordered-columns — Pinterest-style packed column layout

Mon Dec 01 2014 16:00:00 GMT+0000 (UTC)

ordered-columns implements a packed column layout in the style of Pinterest. Home pages with cards or modules that vary in height often use this layout to pack the cards into columns: cards are assigned in order to whichever column is currently the shortest. Such a layout is quick to compute, produces visually engaging results, maximizes content that appears above the fold. It's a useful responsive design pattern that scales well from small displays to very large ones. Many JavaScript libraries exist to implement this pattern, but this is a great example of a pattern that can be delivered as a web component.

Likes: Author Steven Skelton implements this column layout from the ground up as a Polymer web component. We see many, many web components that simply wrap an existing JavaScript library, and while that's a fine way to start, it can also lead to bloat. He also provides good documentation and numerous examples.

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.

See our full details on ordered-columns

akyral-modal – Modal overlay with beautiful demos and documentation

Thu Nov 06 2014 08:00:00 GMT+0000 (UTC)

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.

See our full details on akyral-modal

x-rating — Simple star rating element that works

Mon Nov 03 2014 08:00:00 GMT+0000 (UTC)

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:

  • rating-element. We set aside this one aside when we found that it relies on an image sprite; in this age of responsive design, using an image sprite feels a bit antiquated.
  • polymer-star-rating. This is the most full-featured of the three components we looked at: in particular, it's the only one that lets you can use different symbols for each rating, instead of always using a star. We had some difficulties getting the component to work in a demo of our own. (We filed a bug.) There were some other confusing points as well: the package name (polymer- star-rating) doesn't match the element name (star-rating), and the component made assumptions about the location of dependencies like polymer.html that didn't match up with how we'd set up things. Still, we have high hopes for this component.
  • x-rating. This is the simplest component of the lot, but it worked immediately and did what we wanted. It uses Unicode code glyphs for the stars, which has the advantage of picking up the current text color. The glyph unfortunately isn't a parameter you can change, but that's nevertheless fine for the many cases in which you might want to just use a standard star.

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!

See our full details on x-rating

« Newer Older »