Bringing Componentization to the Web: An Overview of Web Components

This article is part of a web development series from Microsoft. Thank you for supporting the partners who make SitePoint possible.

Four of the five most-requested features on the Microsoft Edge developer suggestion box belong to the family of features called Web Components—Shadow DOM, Template, Custom Elements, and HTML Imports. In this post we’ll talk about Web Components and give our viewpoint, some background for those who may not be intimately familiar with them, and speculate a bit about where we might expect them to evolve in the future. To do it justice requires a bit of length, so sit back, grab a coffee (or non-caffeinated beverage) and read-on.

Componentization: an old design practice made new again for the web

Web applications are now as complex as any other software applications and often take many people coordinating to produce the released product. It is essential to find the right way to divide up the development work with minimal overlap between people and systems in order to be more efficient. Componentization (in general) is how this is done. Any component system should reduce overall complexity by providing isolation, or a natural barrier that hides the complexity of one system from another. Good isolation also makes reusability and serviceability easier.

Initially, web application complexity was managed mostly on the server by isolating the application into separate pages, each requiring the user to navigate their browser from page to page. With the introduction of AJAX and related capabilities, developers no longer needed to “navigate” between different pages of a web application. For some common scenarios like reading email or news, expectations have changed. For example, after logging into your email, you may be “running the email application” from a single URL and stay on that page all day long (aka Single-Page Applications). Client-side web application logic may be much more complex, perhaps even rivaling that of the server side. A possible solution to help solve this complexity is to further componentize and isolate logic within a single web page or document.

The goal of web components is to reduce complexity by isolating a related group of HTML, CSS, and JavaScript to perform a common function within the context of a single page.

How to componentize?

Because web components must draw together each of HTML, CSS, and JavaScript, the existing isolation models supported by each technology contribute to scenarios that are important to preserve in the whole of web components. These independent isolation models include (and are described in more detail in the following paragraphs):

CSS style isolation

There is no great way to componentize CSS natively in the platform today (though tools like Sass can certainly help). A component model must support a way to isolate some set of CSS from another such that the rules defined in one don’t interfere with the other. Additionally, component styles should apply only to the necessary parts of the component and nothing else. Easier said than done!

Within a style sheet, CSS styles are applied to the document using Selectors. Selectors are always considered with potential applicability to the whole document, thus their reach is essentially global. This global reach leads to real conflicts when many contributors to a project pool their CSS files together. Overlapping and duplicate selectors have an established precedence (e.g., cascade, specificity and source-order) for resolving conflicts, but the emergent behavior may not be what the developers intended. There are many potential solutions to this problem. A simple solution is to move elements and related styles participating in a component from the primary document to a different document (a shadow document) such that they are no longer selector matching candidates. This gives rise to a secondary problem: now that there is a boundary established, how does one style across the boundary? This is obviously possible to do imperatively in JavaScript, but it seems awkward to rely on JavaScript to mediate styles over the boundary for what seems like a gap in CSS.

To transmit styles across a component boundary effectively, and to protect the structure of a component (e.g., allow freedom of structural changes without breaking styles), there are two general approaches that have some consensus: “parts” styling using custom pseudo elements and custom properties (formerly known as CSS “variables”). For a time, the ultra-powerful cross-boundary selector combinator ‘>>>’ was also considered (specified in CSS Scoping), but this is now generally accepted as a bad idea because it breaks component isolation too easily.

Continue reading %Bringing Componentization to the Web: An Overview of Web Components%

Source: Sitepoint