Skip to toolbar

Community & Business Groups

Declarative Dynamic Extensions to HTML Community Group

The mission of this group is to write the specification of a set of HTML declarative extensions that allow :

  • to write factorised HTML (with help of the handlebars template engine), perform some advanced dynamic behaviors (without javascript requirements),
  • and resolve some separation of concerns problems by adding a design layer between styles and the html document itself.

This declarative design layer will provide, by external XML resources (initially called XML Design System Sheets) subset of handlebars templates to describe how user agent have to render the shadow dom of classical HTML elements.
Moreover, the dynamic behaviours will use the data representation separations allowed by integrating model instance elements from XForms to HTML itself. To complete it, an extension will propose a new way to retrieve datas as a form control replacement based on the editor attribute, inspired from XForms specification.

This group will produce reports after discussions, specification(s), and maybe a javascript experimental implementation. One or more of this skills and expertise are desired from participants : HTML, XML, Javascript, and an attention to the importance of the javascript unobstrusive recommendation (declarative HTML should be full functionnal , security reasons, stability...).

This group may publish Specifications.

Group's public email, repo and wiki activity over time

Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

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.

Call for Participation in Declarative Dynamic Extensions to HTML Community Group

The Declarative Dynamic Extensions to HTML Community Group has been launched:


The mission of this group is to write the specification of a set of HTML declarative extensions
that allow :

  • to write factorised HTML (with help of the handlebars template engine), perform some advanced dynamic behaviors (without javascript requirements),
  • and resolve some separation of concerns problems by adding a design layer between styles and the html document itself.

This declarative design layer will provide, by external XML resources (initially called XML Design System Sheets) subset of handlebars templates to describe how user agent have to render the shadow dom of classical HTML elements.
Moreover, the dynamic behaviours will use the data representation separations allowed by integrating model instance elements from XForms to HTML itself. To complete it, an extension will propose a new way to retrieve datas as a form control replacement based on the editor attribute, inspired from XForms specification.

This group will produce reports after discussions, specification(s), and maybe a javascript experimental implementation. One or more of this skills and expertise are desired from participants : HTML, XML, Javascript, and an attention to the importance of the javascript unobstrusive recommendation (declarative HTML should be full functionnal , security reasons, stability…).

This group may publish Specifications.


In order to join the group, you will need a W3C account. Please note, however, that W3C Membership is not required to join a Community Group.

This is a community initiative. This group was originally proposed on 2023-03-07 by Guillon Flavien. The following people supported its creation: Guillon Flavien, Kristina Gudim, Jean Belicot, Fabien Stéfaniak, Haerul Fuad. W3C’s hosting of this group does not imply endorsement of the activities.

The group must now choose a chair. Read more about how to get started in a new group and good practice for running a group.

We invite you to share news of this new group in social media and other channels.

If you believe that there is an issue with this group that requires the attention of the W3C staff, please email us at site-comments@w3.org

Thank you,
W3C Community Development Team