Web Components Pitfalls

Web Components composed of Custom Elements, Templates, Shadow DOM and HTML Imports definitely solve CSS problems which cause front-end developer trouble.

It’s easy to use distributed Web Components, but I think it’s really doubtful that processing HTML components using Web Components will become popular. It’s too difficult to create Web Components with a full understanding their specs in a conventional way (eg. writing native HTML, and styling it with CSS).

the difficult route by Mattijn Franssen

It’s only shifting the problem from worrying about CSS scope to worrying about a Web Components architecture, isn’t it?

Technical Awkwardness with Web Components

It’s too difficult to use Shadow DOM only to solve the CSS scope problem for the developer. In addition, shifting the description style from Declarative to Imperative may be a little boring for non-programmers.

<template>
  <style>
    input {...}
    button {...}
  </style>
  <input type="text">
  <button>Button</button>
</template>
<script>
  var ownerDocument = document.currentScript.ownerDocument;
  var ElementPrototype = Object.create(HTMLElement.prototype);
  ElementPrototype.createdCallback = function () {
    var template = ownerDocument.querySelector('template');
    var clone = document.importNode(template.content, true);
    this.shadowRoot = this.createShadowRoot();
    this.shadowRoot.appendChild(clone);
  };
  document.registerElement('sample-element', {
    prototype: ElementPrototype
  });
</script>

Polymer attempts to make these steps simpler. Troublesome API calling from JavaScript to create a Shadow DOM is omitted through the use of the Polymer Element. The following code is written in Polymer style (version 0.5):

<polymer-element name="sample-element" noscript>
  <template>
    <style>
      input {...}
      button {...}
    </style>
    <input type="text">
    <button>Button</button>
  </template>
</polymer-element>

Element registration way is changed in newest Polymer (version 0.8). But it’s already easier than Pure Web Components style.

<dom-module id="sample-element">
  <style>
    input {...}
    button {...}
  </style>
  <template>
    <input type="text">
    <button>Button</button>
  </template>
</dom-module>
<script>
  var SampleElement = Polymer({is: 'sample-element'});
</script>

Trying to simplify this process is important.

I don’t know which is correct — whether the spec should be simple for developers, or libraries such as Polymer should simplify complex specs. But the gap between them will be closed in time.

Difficulty Processing Components

There is not a lot of know-how gathered about Componentizatoin. A developer learns mainly through experience about:

• Which features the component include
• Which is public attribute
• Abstractness and versatility
• Components consistency

First, we should share the idea of Componentizing with designers.

Laura + Jaime Wedding | Mercury Hall by The Simplifiers

The scope provided by Shadow DOM should be praised. But don’t forget that we can style the Shadow DOM from outside through selectors such as “::shadow”, “>>>” combinator.

Eric Bidelman said in Shadow DOM 201 — HTML5Rocks.

As authors of custom elements, we have a ton of options for controlling the look and feel of our content. Shadow DOM forms the basis for this brave new world.

Shadow DOM gives us scoped style encapsulation and a means to let in as much (or as little) of the outside world as we choose. By defining custom pseudo elements or including CSS Variable placeholders, authors can provide third-parties convenient styling hooks to further customize their content. All in all, web authors are in full control of how their content is represented.

Adding the above selectors to temporarily fix styling causes the same mistakes as before. In the end, we should refactor and be literate in dealing with Web Components.