One Composer, Real Code
Why UiChemy ships a single flexible widget instead of a fixed widget library, and why that widget stores actual HTML, CSS, and JavaScript rather than configuration.
Most WordPress page builder plugins that extend Elementor ship a library of dozens of widgets, a hero widget, a testimonials widget, a pricing widget, a team grid widget. UiChemy ships one: the Composer widget. Understanding why that decision was made, and what it means for how the widget works, is the foundation for understanding everything else in UiChemy.
The Problem With Widget Libraries
When a plugin ships a pricing widget, that widget outputs pricing HTML. You can configure the number of columns, the colors, the labels, but you cannot change what the widget fundamentally is. If you need a pricing table that looks different from what the widget supports, you're stuck, or you're writing custom CSS to override a structure you don't control.
This isn't a criticism, it's just a constraint. Fixed-structure widgets are predictable and easy to configure. But when your design is custom, the constraints become friction.
What the Composer Widget Does Instead
The Composer widget has no fixed structure. It's a container that stores whatever HTML, CSS, and JavaScript you put inside it. The design, the real code, lives inside the widget itself.
This means:
- A hero section is a Composer widget with hero HTML, hero CSS, and hero JS inside it.
- A pricing table is a Composer widget with pricing HTML, pricing CSS, and pricing JS inside it.
- A navigation bar is a Composer widget with nav HTML, nav CSS, and nav JS inside it.
The widget adapts to whatever you put in it. One widget, unlimited section types.
The Design Is Real Code
The key distinction is that Composer stores code, not configuration. When a traditional widget stores "number of columns: 3", Composer stores the actual HTML for those three columns: <div class="grid-3">, the markup for each card, the CSS that makes them lay out in three columns.
This has several important implications:
- You are not limited by what a widget can output. If you can write it in HTML and CSS, it can go in a Composer widget: custom grid layouts, complex animations, multi-level navigation menus, interactive JavaScript components, all of it works.
- AI can write and edit it. Because the output is real code, an AI that knows HTML and CSS can generate it, read it, and modify it. This is why Chat AI and MCP integration work, the AI isn't configuring a widget, it's writing code.
- The design is portable. Copy a Composer widget from one page to another and the entire design, HTML structure, CSS styles, JavaScript behavior, moves with it. There are no external stylesheets or scripts to reconnect.
CSS Auto-Scoping
When you write CSS inside a Composer widget, the plugin automatically rewrites every rule to be specific to that widget's unique selector. A rule you write as:
h2 { font-size: 2rem; }
gets transformed internally to something like:
.uichemy-composer-abc123 h2 { font-size: 2rem; }
This means your widget's styles cannot affect other elements on the page, and styles from one Composer widget cannot bleed into another. You write CSS normally; scoping is automatic.
The exact scoping selector depends on the builder: Gutenberg and Bricks use a UiChemy-generated class like the example above. In Elementor, the widget reuses Elementor's own native per-instance class instead of minting a new one, the effect is identical either way, styles stay contained to that widget.
What This Means for Developers
If you're a developer, the Composer widget is essentially a scoped HTML/CSS/JS sandbox inside Elementor. You write real code, it renders real output, and it's scoped so it cannot break anything else on the page.
You don't fight Elementor's component system. You don't write override CSS on top of widget output you can't control. You write the design directly.
What This Means for Designers and Content Editors
Even though the widget stores code, you don't need to touch code to use it. Slots automatically extract every text, link, and image from the widget's HTML and surface them as editable fields in the Elementor panel.
Chat AI can generate the initial code from a plain-English description. Once the design exists, content editors can update text and swap images through the panel, never opening the code editor.
Use Cases
- Building a custom section a fixed widget library can't produce, complex grid layouts, animations, or a multi-level nav menu.
- Letting AI write and edit real code, instead of configuring settings on a fixed widget, Chat AI and MCP generate actual HTML/CSS/JS.
- Reusing one design across multiple pages, copy a Composer widget and the entire design, HTML, CSS, and JS, moves with it, no external stylesheets to reconnect.