Custom Elements and unobstrusive Javascript

Custom Elements give us the ability to encapsulate our components, making them easy to export, compatible with any framework. From the JavaScript developer’s perspective, custom elements are welcome because the code isolation they allow makes them highly reusable. However, their use is not without posing a certain number of problems.

Fragmentation of knowledge

Each component pack brings its own logic, and each element works with its specific attributes, in its own way. Consequently, each HTML page implementing a set of custom elements works with its own logic and requires the reading of one or more specific documentation. The pollyfills do not suffer from this problem because they are intended to make the user experience consistent, and to fill in the absences or implementation defects on the User Agent side, from previously defined and standardized HTML elements. On the contrary, Custom Elements dispense with common standardization and transform HTML (an originally common language, the result of a long collective work of standardization) into a vast set of variants. It’s the Tower of Babel effect.

Native JavaScript dependency

Custom Elements natively depend on JavaScript. This can be considered a security flaw. Here, we will not start from the principle that today the world has chosen to accept that JavaScript is essential, and that we have to deal with it. The situation is only irreversible if no one tries to fix it, and the reasons that made unobtrusive JavaScript a good practice have not gone away.

How to solve these problems ?

There is an essential and unavoidable starting point. If we want our HTML page to work without Javascript, it should only be written with standard HTML elements (non-custom). During the loading of the page, certain elements can then be replaced by custom elements, like pollyfills. (To do this, we can for example use the API MutationObserver.)

In a future article we will try to study different approaches that can be complementary. We will analyze the possibilities offered by one or more existing solutions. (Such as this one: https://github.com/flavi1/js-or-not-js/blob/main/README.md under development.) Finally we will show that it is possible to implement n’ any existing custom element even if it does not respect the pattern that we are currently trying to develop. We will see that this gives us the secondary benefit of increasing the reusability of custom elements, making them easily interchangeable.

A few principles to follow

1 – Interoperability: Each Custom Element must mimic the behavior of a classic HTML element and support the same attributes.

• This only concerns the first level Custom Elements. Those included in the document’s DOM. Custom Elements included in the shadow DOM of another element are not affected by this restriction.
• Appearance data will need to be passed to Custom Elements through CSS properties or variables.
• We can use custom attributes (prefixed by data-) to extend the elements with behaviors that are not essentials. (We have to stay unobstrusive)

2 – Accessibility: In the Custom Elements shadow DOM, ARIA roles and attributes have to be used to ensure compatibility with assistive technologies.

Thank you for reading this article. Fell free to post comments here.